From forax at univ-mlv.fr  Sun Oct  1 17:26:35 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 1 Oct 2023 19:26:35 +0200 (CEST)
Subject: Escape-this analysis throw an exception
Message-ID: <1289346093.9971148.1696181195678.JavaMail.zimbra@univ-eiffel.fr>

Hello,
while playing with the escape-this new analysis, i've found a bug

import java.util.function.Supplier;

public class EscapeThis4 {
  public EscapeThis4() {
    System.out.println((Supplier<Object>)  () -> this);
  }
}


% javac -Xlint:all EscapeThis4.java
An exception has occurred in the compiler (21). Please file a bug against the Java compiler via the Java bug reporting page (https://bugreport.java.com) after checking the Bug Database (https://bugs.java.com) for duplicates. Include your program, the following diagnostic, and the parameters passed to the Java compiler in your report. Thank you.
java.lang.AssertionError
        at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
        at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.checkInvariants(ThisEscapeAnalyzer.java:1209)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitScoped(ThisEscapeAnalyzer.java:1103)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.lambda$visitLambda$24(ThisEscapeAnalyzer.java:732)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitDeferred(ThisEscapeAnalyzer.java:1073)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitLambda(ThisEscapeAnalyzer.java:732)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCLambda.accept(JCTree.java:1993)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.scan(ThisEscapeAnalyzer.java:462)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitTypeCast(ThisEscapeAnalyzer.java:949)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCTypeCast.accept(JCTree.java:2204)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.scan(ThisEscapeAnalyzer.java:462)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.invokeUnknown(ThisEscapeAnalyzer.java:623)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.invoke(ThisEscapeAnalyzer.java:552)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitApply(ThisEscapeAnalyzer.java:530)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1816)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.scan(ThisEscapeAnalyzer.java:462)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitExec(ThisEscapeAnalyzer.java:915)
        at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1603)
        at jdk.compiler/com.sun.tools.javac.tree.TreeScanner.scan(TreeScanner.java:50)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.scan(ThisEscapeAnalyzer.java:462)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.analyzeStatements(ThisEscapeAnalyzer.java:419)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.lambda$analyzeTree$6(ThisEscapeAnalyzer.java:358)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitScoped(ThisEscapeAnalyzer.java:1102)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.visitTopLevel(ThisEscapeAnalyzer.java:1052)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.lambda$analyzeTree$7(ThisEscapeAnalyzer.java:357)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
        at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:179)
        at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
        at java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1939)
        at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509)
        at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499)
        at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
        at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
        at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
        at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:596)
        at jdk.compiler/com.sun.tools.javac.comp.ThisEscapeAnalyzer.analyzeTree(ThisEscapeAnalyzer.java:356)
        at jdk.compiler/com.sun.tools.javac.comp.Flow.analyzeTree(Flow.java:233)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1418)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.flow(JavaCompiler.java:1392)
        at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:978)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:319)
        at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:178)
        at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
        at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)

regards,
R?mi

From archie.cobbs at gmail.com  Sun Oct  1 19:09:15 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 1 Oct 2023 14:09:15 -0500
Subject: Escape-this analysis throw an exception
In-Reply-To: <1289346093.9971148.1696181195678.JavaMail.zimbra@univ-eiffel.fr>
References: <1289346093.9971148.1696181195678.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANSoFxvtizApya9hi_=Tbp7XRTfWX39WC-K3TJ4oJieEg2TqAw@mail.gmail.com>

On Sun, Oct 1, 2023 at 12:27?PM Remi Forax <forax at univ-mlv.fr> wrote:

> while playing with the escape-this new analysis, i've found a bug
>

I'll take a look. Seems like we have an invariant that's actually a variant
:)

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231001/5db7eee8/attachment.htm>

From acobbs at openjdk.org  Sun Oct  1 19:55:58 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 1 Oct 2023 19:55:58 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
Message-ID: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>

The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.

This patch relaxes this invariant check to allow for this case.

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

Commit messages:
 - Fix incorrect invariant assertion in this escape analysis.

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

PR: https://git.openjdk.org/jdk/pull/16001

From forax at univ-mlv.fr  Mon Oct  2 07:14:41 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 2 Oct 2023 09:14:41 +0200 (CEST)
Subject: Escape this analysis does not consider anonymous class/local class
Message-ID: <1418642090.10336306.1696230881758.JavaMail.zimbra@univ-eiffel.fr>

Hello,
The compiler does not emit a warning when the access to "this" is buried inside an anonymous class

public class EscapeThis3 {
  public EscapeThis3() {
    new Object() {
      void hidden() {
        for (var field : EscapeThis3.this.getClass().getFields()) {   // calling getClass() is I believe Ok here
          try {
            System.out.println(field.get(EscapeThis3.this));    // but not Ok here !
          } catch (IllegalAccessException e) {
            throw new AssertionError(e);
          }
        }
      }
    }.hidden();
  }
}

or a local class

public class EscapeThis3Bis {
  public EscapeThis3Bis() {
    class Hidden {
      void hidden() {
        for (var field : EscapeThis3Bis.this.getClass().getFields()) {
          try {
            System.out.println(field.get(EscapeThis3Bis.this));
          } catch (IllegalAccessException e) {
            throw new AssertionError(e);
          }
        }
      }
    }
    new Hidden().hidden();
  }
}

regards,
R?mi

From asotona at openjdk.org  Mon Oct  2 08:34:19 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 08:34:19 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed javadoc typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/77631a78..df02df8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 08:34:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 08:34:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
 <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>
Message-ID: <M0oasAxNXAidAqj_vRp8iypQlLegRNWLI_qsp8iehok=.ccdcc5c1-cb83-4b2e-bb7b-acddfa800513@github.com>

On Fri, 29 Sep 2023 23:00:44 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   PreviewFeature annotated with JEP 457
>
> make/jdk/src/classes/build/tools/module/GenModuleInfoSource.java line 476:
> 
>> 474:                         throw parser.newError("is malformed");
>> 475:                     }
>> 476:                 } else if (token.equals("import")) {
> 
> why was this change necessary?

It allows to use imports in module infos, so annotations do not need to use FQN.

> src/java.base/share/classes/java/lang/classfile/AnnotationElement.java line 34:
> 
>> 32: import jdk.internal.javac.PreviewFeature;
>> 33: 
>> 34: /**
> 
> shouldn't we have the preview header applied to all these compilation units?:
> 
> 
> {@preview Associated with pattern matching for instanceof, a preview feature of the Java language.

I'm not aware of preview javadoc tag, could you point me to an example?

> src/java.base/share/classes/java/lang/classfile/Attributes.java line 174:
> 
>> 172:     public static final String NAME_RUNTIME_INVISIBLE_ANNOTATIONS = "RuntimeInvisibleAnnotations";
>> 173: 
>> 174:     /** RuntimeInvisibleTypeAnnotations */
> 
> this comment should probably be: RuntimeInvisibleParameterAnnotations

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342320443
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342347591
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342319521

From abimpoudis at openjdk.org  Mon Oct  2 10:19:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Oct 2023 10:19:40 GMT
Subject: RFR: 8314578: Non-verifiable code is emitted when two guards declare
 pattern variables in colon-switch
Message-ID: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>

In the following example while the case pattern does not introduce binding variable, the guard does. `hasBindings` has been updated accordingly to accept any trees and check them if they contain a `visitBindingPattern`. Not only `JCPattern`'s.


static void test(Object o) {
    switch (o) {
      case R1() when o instanceof String s:
      case R2() when o instanceof Integer i:
        System.out.println("hello: " + i);
        break;
      default:
        break;
    }
  }

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

Commit messages:
 - 8314578: Non-verifiable code is emitted when two guards declare pattern variables in colon-switch

Changes: https://git.openjdk.org/jdk/pull/15630/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15630&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8314578
  Stats: 41 lines in 3 files changed: 38 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15630/head:pull/15630

PR: https://git.openjdk.org/jdk/pull/15630

From mcimadamore at openjdk.org  Mon Oct  2 13:33:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 13:33:36 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/ClassTransform.java line 164:

> 162: 
> 163:     /**
> 164:      * @implSpec

Should these overridden method have `@inheritDoc` ? If not, their javadoc won't show much, I believe. (same might be true for other methods)

src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 596:

> 594:      * @param type the object type
> 595:      * @return this builder
> 596:      * @throws IllegalArgumentException if {@code type} represents a primitive type

What about arrays? (ClassDesc has an `isArray` predicate too). This probably applies to other methods too.

src/java.base/share/classes/java/lang/classfile/CodeTransform.java line 101:

> 99: 
> 100:     /**
> 101:      * @implSpec The default implementation returns a resolved transform;

`... returns a resolved transform that is bound to the given code builder`
or
`... returns a resolved transform bound to the given code builder`

src/java.base/share/classes/java/lang/classfile/FieldTransform.java line 116:

> 114: 
> 115:     /**
> 116:      * @implSpec The default implementation returns a resolved transform with all

Perhaps lose the `all its parts` - not sure that makes the comment any clearer?

src/java.base/share/classes/java/lang/classfile/MethodSignature.java line 59:

> 57: 
> 58:     /**
> 59:      * {@return method signature for a raw (no generic information) method descriptor}

Isn't this missing an article - e.g. `return the method signature` or `return a method signature` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342685585
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342691511
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342693515
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342694834
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342696367

From mcimadamore at openjdk.org  Mon Oct  2 13:33:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 13:33:36 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
Message-ID: <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>

On Mon, 2 Oct 2023 13:19:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/ClassTransform.java line 164:
> 
>> 162: 
>> 163:     /**
>> 164:      * @implSpec
> 
> Should these overridden method have `@inheritDoc` ? If not, their javadoc won't show much, I believe. (same might be true for other methods)

(To be precise - the javadoc says "Description copied from interface: ClassFileTransform") - just make sure that's what you want.

> src/java.base/share/classes/java/lang/classfile/FieldTransform.java line 116:
> 
>> 114: 
>> 115:     /**
>> 116:      * @implSpec The default implementation returns a resolved transform with all
> 
> Perhaps lose the `all its parts` - not sure that makes the comment any clearer?

I've noted the same pattern in other similar methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342689301
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342697392

From mcimadamore at openjdk.org  Mon Oct  2 13:38:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 13:38:23 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <yjL4Gjlc2ZTikZiyK6h3RuaVMw6SHTFu7tAlyPEGArQ=.66c1badd-877f-46ba-9655-d7a14e29cb81@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 310:

> 308:          * @param implClasses the implementation classes
> 309:          * @return this builder
> 310:          * @throws IllegalArgumentException if {@code service} or any of the {@code implClasses} represents a primitive type

Javadoc tip (not that you should use that here) - if the thrown clause becomes too complex, you can also split it into multiple `throws IllegalArgumentException`. Sometimes that can improve readability.

src/java.base/share/classes/java/lang/classfile/attribute/ModuleResolutionAttribute.java line 75:

> 73:      *  The value of the resolution_flags item is a mask of flags used to denote
> 74:      *  properties of module resolution. The flags are as follows:
> 75:      * <pre> {@code

Why not a snippet?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342702250
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342703022

From mcimadamore at openjdk.org  Mon Oct  2 13:43:24 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 13:43:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <ueYjUJ0DrAFhZ9s3vn8SJWZESdVKgODmkwKZoG52b5A=.c409500f-1472-468e-a154-5a7321df9abb@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/attribute/package-info.java line 27:

> 25: 
> 26: /**
> 27:  * <h2>Provides interfaces describing classfile attributes for the {@link java.lang.classfile} library.</h2>

Not 100% sure about the use of `h2` (here and elsewhere).

src/java.base/share/classes/java/lang/classfile/components/ClassPrinter.java line 51:

> 49:  * Level of details to print or to export is driven by {@link Verbosity} option.
> 50:  * <p>
> 51:  * Printing is for debugging purposes only. Printed text schema and tree content and structure

Suggestion:

 * Printing is for debugging purposes only. Printed text schema, tree content and structure

src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java line 71:

> 69:      * Creates a new instance of CodeRelabeler using provided {@link java.util.function.BiFunction}
> 70:      * to re-label the code.
> 71:      * @param mapFunction function remapping labels

I found this a bit hard to read. Maybe expand to "function for remapping labels in the source code model", or something similar

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342707029
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342707621
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342709706

From asotona at openjdk.org  Mon Oct  2 14:01:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:01:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
 <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
Message-ID: <k0O-eFPr_sNlIDJfYlwWAE9ADhpg271mtrsqQGz7lhI=.9bd6afa7-f5be-4eb7-8b07-cc9a56f0b04d@github.com>

On Mon, 2 Oct 2023 13:23:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/ClassTransform.java line 164:
>> 
>>> 162: 
>>> 163:     /**
>>> 164:      * @implSpec
>> 
>> Should these overridden method have `@inheritDoc` ? If not, their javadoc won't show much, I believe. (same might be true for other methods)
>
> (To be precise - the javadoc says "Description copied from interface: ClassFileTransform") - just make sure that's what you want.

The javadoc shows what is expected, so I'm not sure `@inheritDoc` is still required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342720357

From asotona at openjdk.org  Mon Oct  2 14:01:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:01:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
Message-ID: <OU1etT2-Nagq6VEP9oPhw5johZywIR0tPpqJBWHJEPs=.3cb7d002-03ae-4eac-be94-4680b38acc3b@github.com>

On Mon, 2 Oct 2023 13:24:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/CodeBuilder.java line 596:
> 
>> 594:      * @param type the object type
>> 595:      * @return this builder
>> 596:      * @throws IllegalArgumentException if {@code type} represents a primitive type
> 
> What about arrays? (ClassDesc has an `isArray` predicate too). This probably applies to other methods too.

Test for arrays is not performed. The only constraint here is ability to construct constant pool class entry, which is not possible from a primitive type.
The library does only bare minimal consistency checks and proposal for additional constraints should be discussed at the mailing list.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342731348

From mcimadamore at openjdk.org  Mon Oct  2 14:01:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:01:36 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
Message-ID: <lS0_dNEGO8_t4Dvc1dNw8Jmgq3NoJ5kep8SKdZ-O2yk=.f62606d2-eb3a-4f60-82a4-d3d6754c261f@github.com>

On Mon, 2 Oct 2023 13:50:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 67:
> 
>> 65: 
>> 66:     /**
>> 67:      * {@return for an {@code invokeinterface}, the {@code count} value, as defined in {@jvms 6.5}}
> 
> Suggestion:
> 
>      * {@return the {@code count} value of an {@code invokeinterface} instruction, as defined in {@jvms 6.5}}

What does this return for something that is not `invokeinterface` ? Do we infer the count from the descriptor? Or do we return -1 ? This should probably be reflected in the javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342721975

From mcimadamore at openjdk.org  Mon Oct  2 14:01:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:01:36 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 158:

> 156:      */
> 157:     default ClassEntry classEntry(ClassDesc classDesc) {
> 158:         if (requireNonNull(classDesc).isPrimitive()) {

It is not clear to me as to whether all the methods in the API deal with null correctly. What we did for FFM, assuming that the classfile API is also null-hostile by default, was to add a single test which would try to call all API methods and looking for NPEs:

https://github.com/openjdk/jdk/blob/2637e8ddc4ffe102418139f501fc0be8e9c5317b/test/jdk/java/foreign/TestNulls.java#L80

This test has saved us many times when adding/changing API methods.

src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java line 77:

> 75:      * A flags word, indicating the kind of range.  Multiple flag bits
> 76:      * may be set.  Valid flags include
> 77:      * {@link java.lang.classfile.ClassFile#CRT_STATEMENT},

Maybe it would be better to organize the links in a bullet list?

src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 67:

> 65: 
> 66:     /**
> 67:      * {@return for an {@code invokeinterface}, the {@code count} value, as defined in {@jvms 6.5}}

Suggestion:

     * {@return the {@code count} value of an {@code invokeinterface} instruction, as defined in {@jvms 6.5}}

src/java.base/share/classes/java/lang/classfile/package-info.java line 254:

> 252:  * No consistency checks are performed while building or transforming classfiles
> 253:  * (except for null arguments checks). All builders and classfile elements factory
> 254:  * methods accepts provided information without implicit validation.

Suggestion:

 * methods accepts the provided information without implicit validation.

src/java.base/share/classes/java/lang/classfile/package-info.java line 255:

> 253:  * (except for null arguments checks). All builders and classfile elements factory
> 254:  * methods accepts provided information without implicit validation.
> 255:  * However fatal inconsistencies (like for example invalid code sequence or

Suggestion:

 * However, fatal inconsistencies (like for example invalid code sequence or

src/java.base/share/classes/java/lang/classfile/package-info.java line 259:

> 257:  * the classfile building process.
> 258:  * <p>
> 259:  * Basic syntax control can be achieved using symbolic descriptors. For example

What does "syntax control" mean? The concept is used, but not defined, in the javadoc. (I presume we mean eg.g. turning String into `Ljava/lang/String;`)

src/java.base/share/classes/java/lang/classfile/package-info.java line 266:

> 264:  * On the other hand it is possible to use builders methods and factories accepting
> 265:  * constant pool entries to avoid any form of syntax control. Constant pool entries
> 266:  * can be constructed from raw values, where no syntax control is in charge.

Suggestion:

 * can be constructed from raw values, with no additional syntactic checks.

src/java.base/share/classes/java/lang/classfile/package-info.java line 273:

> 271:  * <p>
> 272:  * More complex verification of a classfile can be achieved by explicit invocation
> 273:  * of {@link java.lang.classfile.ClassModel#verify}.

Aren't part of verification also ran as part of generating stackmaps (unless stackmap inference is disabled) ? Should it be mentioned here?

src/java.base/share/classes/java/lang/classfile/package-info.java line 386:

> 384:  * resulting in many unreferenced constant pool entries.
> 385:  *
> 386:  * <h3>Transformation handling of unknown classfile elements from a future</h3>

>From a future... ? JDK?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342714653
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342716987
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342720961
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342724684
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342725264
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342726203
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342728341
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342730435
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342730871

From asotona at openjdk.org  Mon Oct  2 14:20:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:20:17 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v4]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <9AHA5Q0Hh40IVCHedBXufW0fbphSk_SrcdHQKhpHthI=.5128350b-ac18-4f02-a3a2-18a72a2a97e5@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - fixing javadoc
 - fixing javadoc
 - fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/df02df8f..75be7e89

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=02-03

  Stats: 9 lines in 5 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:20:24 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:20:24 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
Message-ID: <-TSw34evJdBqh-rwtz2D0KxhdzD4EaiEMjuYY3MIsMs=.f4c7571b-4e46-421e-a339-070843fbcc3a@github.com>

On Mon, 2 Oct 2023 13:26:38 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/CodeTransform.java line 101:
> 
>> 99: 
>> 100:     /**
>> 101:      * @implSpec The default implementation returns a resolved transform;
> 
> `... returns a resolved transform that is bound to the given code builder`
> or
> `... returns a resolved transform bound to the given code builder`

Fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/MethodSignature.java line 59:
> 
>> 57: 
>> 58:     /**
>> 59:      * {@return method signature for a raw (no generic information) method descriptor}
> 
> Isn't this missing an article - e.g. `return the method signature` or `return a method signature` ?

Fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/attribute/ModuleAttribute.java line 310:
> 
>> 308:          * @param implClasses the implementation classes
>> 309:          * @return this builder
>> 310:          * @throws IllegalArgumentException if {@code service} or any of the {@code implClasses} represents a primitive type
> 
> Javadoc tip (not that you should use that here) - if the thrown clause becomes too complex, you can also split it into multiple `throws IllegalArgumentException`. Sometimes that can improve readability.

Thanks!

> src/java.base/share/classes/java/lang/classfile/attribute/ModuleResolutionAttribute.java line 75:
> 
>> 73:      *  The value of the resolution_flags item is a mask of flags used to denote
>> 74:      *  properties of module resolution. The flags are as follows:
>> 75:      * <pre> {@code
> 
> Why not a snippet?

It is a citation from the spec, not sure a snippet would be appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342738626
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342745504
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342745325
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342748330

From asotona at openjdk.org  Mon Oct  2 14:20:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:20:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ZAGR1IcZTpeh3oVk31UUHXymTK1TS5_jQYikV_FJFGA=.1c187d91-7cf8-48f7-8769-3302d05ce2f8@github.com>
 <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
Message-ID: <sfSoC4EmTOU9yDEcu-0tdlfgR9PjKGNs0aid7dvyOIQ=.3bfe5a83-e2e6-43f9-aefa-70c51bd34b48@github.com>

On Mon, 2 Oct 2023 13:29:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/FieldTransform.java line 116:
>> 
>>> 114: 
>>> 115:     /**
>>> 116:      * @implSpec The default implementation returns a resolved transform with all
>> 
>> Perhaps lose the `all its parts` - not sure that makes the comment any clearer?
>
> I've noted the same pattern in other similar methods

Fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342742531

From mcimadamore at openjdk.org  Mon Oct  2 14:20:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:20:30 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

src/java.base/share/classes/java/lang/classfile/package-info.java line 389:

> 387:  * To achieve stability of transformations in future JDK releases it is desired
> 388:  * to set appropriate response to potential new classfile elements appearing.
> 389:  * Transformation designed to handle all situation should be implemented strict way,

"handle all situations" - I couldn't make much sense of it. I only got it when reading the text that follows, which says "transformation selectively interested in ...". This para should be rephrased for better clarity. E.g.
"Classfile transforms that are interested in consuming _all_ classfile elements should be implemented in a strict fashion, so that new exceptions will be issued, should a new and unknown classfile element appear ... Conversely, classfile transforms that are only interested in consuming a portion of classfile elements do not need to concern with new and unknown classfile elements ... because ... "

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342737274

From asotona at openjdk.org  Mon Oct  2 14:25:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:25:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v5]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <NjjhV3QnyTqihG7ESKy03FQn-2xrZUGgN47yzrRt3XM=.88185003-cd57-450d-ba50-1951979f82bd@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/classfile/components/ClassPrinter.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/75be7e89..ea31ec98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:29:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:29:56 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v6]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <meUDcNfMecwZYJ6CqSFb3oQ0Pmz0HtjoOF2AjR3cWUY=.59492997-8f2e-4fdd-8f83-d5b0ad5c8c0b@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/ea31ec98..dc2dfd30

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:42:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:42:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v7]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <rIRmxp3ZauZcIqDgzdijwYuBV5IBU3hb1MnWazQS97c=.c13d2333-0834-45a1-a1fb-c9dbc46b4488@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/dc2dfd30..bd84bf93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  2 14:43:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 14:43:02 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <ueYjUJ0DrAFhZ9s3vn8SJWZESdVKgODmkwKZoG52b5A=.c409500f-1472-468e-a154-5a7321df9abb@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ueYjUJ0DrAFhZ9s3vn8SJWZESdVKgODmkwKZoG52b5A=.c409500f-1472-468e-a154-5a7321df9abb@github.com>
Message-ID: <X3GhDpB0IGdCLTK4xwbEpgT9kQavYmRtwIr1ZcLawMc=.06a4f6c5-e9eb-406c-b529-4e0992163293@github.com>

On Mon, 2 Oct 2023 13:40:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/components/CodeRelabeler.java line 71:
> 
>> 69:      * Creates a new instance of CodeRelabeler using provided {@link java.util.function.BiFunction}
>> 70:      * to re-label the code.
>> 71:      * @param mapFunction function remapping labels
> 
> I found this a bit hard to read. Maybe expand to "function for remapping labels in the source code model", or something similar

Fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java line 158:
> 
>> 156:      */
>> 157:     default ClassEntry classEntry(ClassDesc classDesc) {
>> 158:         if (requireNonNull(classDesc).isPrimitive()) {
> 
> It is not clear to me as to whether all the methods in the API deal with null correctly. What we did for FFM, assuming that the classfile API is also null-hostile by default, was to add a single test which would try to call all API methods and looking for NPEs:
> 
> https://github.com/openjdk/jdk/blob/2637e8ddc4ffe102418139f501fc0be8e9c5317b/test/jdk/java/foreign/TestNulls.java#L80
> 
> This test has saved us many times when adding/changing API methods.

Good point, thanks.
I've create new RFE https://bugs.openjdk.org/browse/JDK-8317356 because the test would not be so simple to cover all ClassFile API in different situations (for example different builders implementations based on the actual context).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342777997
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342775179

From mcimadamore at openjdk.org  Mon Oct  2 14:45:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:45:31 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <Lr4GQOhS9-3vV3mWPQKzni7uWAHWNWWJKQ-tDeT4LFQ=.2f7b535b-9ddd-40d4-bdd4-86b7fd37148b@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 107:

> 105:     }
> 106: 
> 107: // this version of the code can be used when ClassFile API in not in a preview

Do you want to keep these commented lines? I'm fine (as it seems like you saved the code that was there before, for future reference). I'm just asking as this is a biggie PR, in case something went amiss.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342783513

From abimpoudis at openjdk.org  Mon Oct  2 14:47:59 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Oct 2023 14:47:59 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Implement type pairs to exactnessMethod name
 - Apply suggestions from code review
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/1ae06ac8..ad6071b0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=01-02

  Stats: 28829 lines in 719 files changed: 17870 ins; 8464 del; 2495 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Mon Oct  2 14:48:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Oct 2023 14:48:04 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v2]
In-Reply-To: <EoilLyqaD9Fbx8k1mK-dB7nG_Star3e25rH1YaUfmkA=.88e63d0e-454b-4a7e-93f5-707f0ef034b5@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <VJSasljKDgPWCJx1PkZwF_LJdO0qsX4dw7Icia11L3o=.e8d52a6c-428f-4b41-8618-b2cfa80973dc@github.com>
 <EoilLyqaD9Fbx8k1mK-dB7nG_Star3e25rH1YaUfmkA=.88e63d0e-454b-4a7e-93f5-707f0ef034b5@github.com>
Message-ID: <MZEisgzeSIqeEbhUQwyHNB4GMiqO0o5PFGIS39jTOtM=.45147d74-0b6a-41e8-b768-3852f8364d2f@github.com>

On Fri, 29 Sep 2023 16:17:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply suggestions from code review
>>   
>>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>
> I just had a reading at the `ExactnessMethods` class. From that limited perspective, the methods mentioned above seem redundant.
> But if their removal would make other parts more complex, that's a good reason to keep them.

Pushed an update that removes the methods you pointed out @rgiulietti at the cost of a little duplication between Lower and SwitchBootstraps. Thx for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/15638#issuecomment-1743148778

From mcimadamore at openjdk.org  Mon Oct  2 14:49:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:49:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <Lr4GQOhS9-3vV3mWPQKzni7uWAHWNWWJKQ-tDeT4LFQ=.2f7b535b-9ddd-40d4-bdd4-86b7fd37148b@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <Lr4GQOhS9-3vV3mWPQKzni7uWAHWNWWJKQ-tDeT4LFQ=.2f7b535b-9ddd-40d4-bdd4-86b7fd37148b@github.com>
Message-ID: <Tk2TksWAESLv_hoMSS99HqRCDQ_0J_bk0whZNQzrSFE=.cd54ee89-4c27-4362-894a-dfc94083819e@github.com>

On Mon, 2 Oct 2023 14:40:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 107:
> 
>> 105:     }
>> 106: 
>> 107: // this version of the code can be used when ClassFile API in not in a preview
> 
> Do you want to keep these commented lines? I'm fine (as it seems like you saved the code that was there before, for future reference). I'm just asking as this is a biggie PR, in case something went amiss.

That said, if tests with such usages are not many, we could also consider adding enable-preview to the tests, and just use the new API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342789740

From mcimadamore at openjdk.org  Mon Oct  2 14:59:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:59:28 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <XtmZAh2PhGzdtRLkpxTjVZev7NAY4g2z1et6CdSOTCM=.3e70de2d-b267-4de0-b95a-90c847dd10ce@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

test/langtools/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java line 52:

> 50:         assertNull(
> 51:                 ClassFile.of().parse(getClassFile(NoSourceFileAttribute.class).toPath()).findAttribute(Attributes.SOURCE_FILE).orElse(null),
> 52:                 "ClassFile should have no SourceFile attribute when compiled without debug information.");

Not sure if replacing the camel case ClassFile in the assertion message is what you wanted here

test/langtools/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase_legacy.java line 45:

> 43:  * @see #compileAndTest
> 44:  */
> 45: public class SourceFileTestBase_legacy extends TestBase {

Why is this called "legacy" ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342796933
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342798443

From mcimadamore at openjdk.org  Mon Oct  2 14:59:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 14:59:29 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <XtmZAh2PhGzdtRLkpxTjVZev7NAY4g2z1et6CdSOTCM=.3e70de2d-b267-4de0-b95a-90c847dd10ce@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <XtmZAh2PhGzdtRLkpxTjVZev7NAY4g2z1et6CdSOTCM=.3e70de2d-b267-4de0-b95a-90c847dd10ce@github.com>
Message-ID: <TpLFSoYVAII-UnchyIf2OPu1vT4bwAuDNBtZj7Wr25Q=.04e7b339-71ca-4c81-b8a2-b2972c9d9baa@github.com>

On Mon, 2 Oct 2023 14:52:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> test/langtools/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase_legacy.java line 45:
> 
>> 43:  * @see #compileAndTest
>> 44:  */
>> 45: public class SourceFileTestBase_legacy extends TestBase {
> 
> Why is this called "legacy" ?

Uhmm is this to be used in tests to be compiled against a JDK release where no classfile API is available?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342802259

From forax at univ-mlv.fr  Mon Oct  2 15:04:47 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 2 Oct 2023 17:04:47 +0200 (CEST)
Subject: RFR: 8314578: Non-verifiable code is emitted when two guards
 declare pattern variables in colon-switch
In-Reply-To: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
References: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
Message-ID: <50600388.10987511.1696259087551.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Aggelos Biboudis" <abimpoudis at openjdk.org>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Monday, October 2, 2023 12:19:40 PM
> Subject: RFR: 8314578: Non-verifiable code is emitted when two guards declare pattern variables in colon-switch

> In the following example while the case pattern does not introduce binding
> variable, the guard does. `hasBindings` has been updated accordingly to accept
> any trees and check them if they contain a `visitBindingPattern`. Not only
> `JCPattern`'s.
> 
> 
> static void test(Object o) {
>    switch (o) {
>      case R1() when o instanceof String s:
>      case R2() when o instanceof Integer i:
>        System.out.println("hello: " + i);
>        break;
>      default:
>        break;
>    }
>  }

I think, i've fully understand the issue, what about

static void test(Object o) {
   switch (o) {
     case R1() when o instanceof String _:
     case R2() when o instanceof Integer _:
       System.out.println("hello: " + i);
       break;
     default:
       break;
   }
 }

regards,
R?mi

> 
> -------------
> 
> Commit messages:
> - 8314578: Non-verifiable code is emitted when two guards declare pattern
> variables in colon-switch
> 
> Changes: https://git.openjdk.org/jdk/pull/15630/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15630&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8314578
>  Stats: 41 lines in 3 files changed: 38 ins; 0 del; 3 mod
>  Patch: https://git.openjdk.org/jdk/pull/15630.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15630/head:pull/15630
> 
> PR: https://git.openjdk.org/jdk/pull/15630

From forax at univ-mlv.fr  Mon Oct  2 15:09:07 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 2 Oct 2023 17:09:07 +0200 (CEST)
Subject: RFR: 8314578: Non-verifiable code is emitted when two guards
 declare pattern variables in colon-switch
In-Reply-To: <50600388.10987511.1696259087551.JavaMail.zimbra@univ-eiffel.fr>
References: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
 <50600388.10987511.1696259087551.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <968675352.10992129.1696259347259.JavaMail.zimbra@univ-eiffel.fr>

oops, 
"I've not fully understand the issue" ...

----- Original Message -----
> From: "Remi Forax" <forax at univ-mlv.fr>
> To: "Aggelos Biboudis" <abimpoudis at openjdk.org>
> Cc: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Monday, October 2, 2023 5:04:47 PM
> Subject: Re: RFR: 8314578: Non-verifiable code is emitted when two guards declare pattern variables in colon-switch

> ----- Original Message -----
>> From: "Aggelos Biboudis" <abimpoudis at openjdk.org>
>> To: "compiler-dev" <compiler-dev at openjdk.org>
>> Sent: Monday, October 2, 2023 12:19:40 PM
>> Subject: RFR: 8314578: Non-verifiable code is emitted when two guards declare
>> pattern variables in colon-switch
> 
>> In the following example while the case pattern does not introduce binding
>> variable, the guard does. `hasBindings` has been updated accordingly to accept
>> any trees and check them if they contain a `visitBindingPattern`. Not only
>> `JCPattern`'s.
>> 
>> 
>> static void test(Object o) {
>>    switch (o) {
>>      case R1() when o instanceof String s:
>>      case R2() when o instanceof Integer i:
>>        System.out.println("hello: " + i);
>>        break;
>>      default:
>>        break;
>>    }
>>  }
> 
> I think, i've fully understand the issue, what about
> 
> static void test(Object o) {
>   switch (o) {
>     case R1() when o instanceof String _:
>     case R2() when o instanceof Integer _:
>       System.out.println("hello: " + i);
>       break;
>     default:
>       break;
>   }
> }
> 
> regards,
> R?mi
> 
>> 
>> -------------
>> 
>> Commit messages:
>> - 8314578: Non-verifiable code is emitted when two guards declare pattern
>> variables in colon-switch
>> 
>> Changes: https://git.openjdk.org/jdk/pull/15630/files
>> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15630&range=00
>>  Issue: https://bugs.openjdk.org/browse/JDK-8314578
>>  Stats: 41 lines in 3 files changed: 38 ins; 0 del; 3 mod
>>  Patch: https://git.openjdk.org/jdk/pull/15630.diff
>>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15630/head:pull/15630
>> 
> > PR: https://git.openjdk.org/jdk/pull/15630

From mcimadamore at openjdk.org  Mon Oct  2 15:10:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 15:10:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
Message-ID: <wqSvt1VDv4wkxgb9Bxalqhk0eCfwaZpdk232b77uYWE=.9e685729-0427-40ff-ae39-9d6f343325a9@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed javadoc typo

Completed first pass on the PR. Everything looks ok modulo some minor nits. I like the new came case name for ClassFile :-)

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

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1652950261

From asotona at openjdk.org  Mon Oct  2 15:14:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 15:14:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <TpLFSoYVAII-UnchyIf2OPu1vT4bwAuDNBtZj7Wr25Q=.04e7b339-71ca-4c81-b8a2-b2972c9d9baa@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <XtmZAh2PhGzdtRLkpxTjVZev7NAY4g2z1et6CdSOTCM=.3e70de2d-b267-4de0-b95a-90c847dd10ce@github.com>
 <TpLFSoYVAII-UnchyIf2OPu1vT4bwAuDNBtZj7Wr25Q=.04e7b339-71ca-4c81-b8a2-b2972c9d9baa@github.com>
Message-ID: <ODDKg_BBxiM-SEOeEOWi48t3o5rXwT0grGtLrdvXY_E=.0f4c543e-c067-4fc3-800c-248aa620c890@github.com>

On Mon, 2 Oct 2023 14:56:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/classfiles/attributes/SourceFile/SourceFileTestBase_legacy.java line 45:
>> 
>>> 43:  * @see #compileAndTest
>>> 44:  */
>>> 45: public class SourceFileTestBase_legacy extends TestBase {
>> 
>> Why is this called "legacy" ?
>
> Uhmm is this to be used in tests to be compiled against a JDK release where no classfile API is available?

We need these "legacy" copies while ClassFile API is a preview feature.
Some of the tests require to specify compilation target other than 22 and it is not possible to combine it with enabled preview switch.
Fortunately it affects only very few from the hundreds of tests already converted to ClassFile API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342820255

From vromero at openjdk.org  Mon Oct  2 15:20:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Oct 2023 15:20:32 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v2]
In-Reply-To: <M0oasAxNXAidAqj_vRp8iypQlLegRNWLI_qsp8iehok=.ccdcc5c1-cb83-4b2e-bb7b-acddfa800513@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <WP9SgQV-pB3f5ARx5UZTzcwIh0b60GdeX6c4ogj1ISo=.ed039aae-d398-41d2-bbcc-c7779bb2e3ab@github.com>
 <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>
 <M0oasAxNXAidAqj_vRp8iypQlLegRNWLI_qsp8iehok=.ccdcc5c1-cb83-4b2e-bb7b-acddfa800513@github.com>
Message-ID: <Yft8CKhdzKaYfwTZCpPiqMDMGgyDSgRWDRNsUDlBNYI=.2a8d1cb2-631b-4cfd-a713-8e73da5e1970@github.com>

On Mon, 2 Oct 2023 07:18:19 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/AnnotationElement.java line 34:
>> 
>>> 32: import jdk.internal.javac.PreviewFeature;
>>> 33: 
>>> 34: /**
>> 
>> shouldn't we have the preview header applied to all these compilation units?:
>> 
>> 
>> {@preview Associated with pattern matching for instanceof, a preview feature of the Java language.
>
> I'm not aware of preview javadoc tag, could you point me to an example?

nvm, I was rechecking JEP 12, this javadoc should now be generated automatically so we are good

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342825999

From asotona at openjdk.org  Mon Oct  2 15:20:33 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 2 Oct 2023 15:20:33 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <Tk2TksWAESLv_hoMSS99HqRCDQ_0J_bk0whZNQzrSFE=.cd54ee89-4c27-4362-894a-dfc94083819e@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <Lr4GQOhS9-3vV3mWPQKzni7uWAHWNWWJKQ-tDeT4LFQ=.2f7b535b-9ddd-40d4-bdd4-86b7fd37148b@github.com>
 <Tk2TksWAESLv_hoMSS99HqRCDQ_0J_bk0whZNQzrSFE=.cd54ee89-4c27-4362-894a-dfc94083819e@github.com>
Message-ID: <NmnboIHLa891WEYVo6smwB3t3j8c4jEVvTLC2rCasX4=.3636aa30-4b96-4e0f-bbef-9f06711f1ef7@github.com>

On Mon, 2 Oct 2023 14:45:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/langtools/tools/javac/7166455/CheckACC_STRICTFlagOnclinitTest.java line 107:
>> 
>>> 105:     }
>>> 106: 
>>> 107: // this version of the code can be used when ClassFile API in not in a preview
>> 
>> Do you want to keep these commented lines? I'm fine (as it seems like you saved the code that was there before, for future reference). I'm just asking as this is a biggie PR, in case something went amiss.
>
> That said, if tests with such usages are not many, we could also consider adding enable-preview to the tests, and just use the new API.

Yes, that is proposed temporary solution to do not loose already converted code while ClassFile API is in preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1342824044

From jlahoda at openjdk.org  Mon Oct  2 15:23:11 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 2 Oct 2023 15:23:11 GMT
Subject: RFR: 8317300: javac erroneously allows "final" in front of a
 record pattern
In-Reply-To: <O2KHdJQLfVfTbOpkht3lOCmhE8QLuBCHTocmBZ4tVV4=.9bb2fd68-3700-4234-be04-3cb7f9a6dcf3@github.com>
References: <O2KHdJQLfVfTbOpkht3lOCmhE8QLuBCHTocmBZ4tVV4=.9bb2fd68-3700-4234-be04-3cb7f9a6dcf3@github.com>
Message-ID: <zPVSlf2riHY07uzriGfCEbV0g-BjQHkrOMjXeZAI-DA=.aff11be2-a499-4c02-982a-2b60990e6adc@github.com>

On Sat, 30 Sep 2023 08:00:44 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Introduces the relevant check for `final` in record patterns.

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15997#pullrequestreview-1652973083

From abimpoudis at openjdk.org  Mon Oct  2 16:07:56 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 2 Oct 2023 16:07:56 GMT
Subject: RFR: 8314578: Non-verifiable code is emitted when two guards
 declare pattern variables in colon-switch [v2]
In-Reply-To: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
References: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
Message-ID: <Tsvr_RFVZnesM_Q34qjTzyR17tO-wz5E5XV6QSNV0K8=.804585c7-7d75-4f4b-9e19-11926cde5ace@github.com>

> In the following example while the case pattern does not introduce binding variable, the guard does. `hasBindings` has been updated accordingly to accept any trees and check them if they contain a `visitBindingPattern`. Not only `JCPattern`'s.
> 
> 
> static void test(Object o) {
>     switch (o) {
>       case R1() when o instanceof String s:
>       case R2() when o instanceof Integer i:
>         System.out.println("hello: " + i);
>         break;
>       default:
>         break;
>     }
>   }

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add test with unnamed in guard

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15630/files
  - new: https://git.openjdk.org/jdk/pull/15630/files/6cb25ea7..17c04251

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15630&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15630&range=00-01

  Stats: 13 lines in 2 files changed: 12 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15630.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15630/head:pull/15630

PR: https://git.openjdk.org/jdk/pull/15630

From archie.cobbs at gmail.com  Mon Oct  2 17:30:29 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 2 Oct 2023 12:30:29 -0500
Subject: Escape this analysis does not consider anonymous class/local class
In-Reply-To: <1418642090.10336306.1696230881758.JavaMail.zimbra@univ-eiffel.fr>
References: <1418642090.10336306.1696230881758.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CANSoFxsWdfepXGuquXFJDQwFD+Ebz+HcSdkTPXhKfg3KgqE2CA@mail.gmail.com>

Hi Remi,

On Mon, Oct 2, 2023 at 2:18?AM Remi Forax <forax at univ-mlv.fr> wrote:

> The compiler does not emit a warning when the access to "this" is buried
> inside an anonymous class
>

This is a known limitation. In summary, the analyzer tracks 'this'
references that are outer instance references from the current instance,
but it doesn't track 'this' references that are outer instance references
from arbitrary objects on the stack.

So when you say "new Inner()", the analyzer doesn't track the fact that the
object on top of the stack now has a 'this' reference via its outer
instance.

This is one of the (many) trade-offs that were made between precision vs.
code complexity.

There are a couple of possible ways to address this:

   1. Using existing reference types: record "new Inner()" as having an
   indirect 'this' reference, and then update the logic for "Outer.this" to
   pessimistically assume any indirect reference is an outer reference.
   2. Add a new reference type: OuterExprRef to mean "a 'this' reference
   from the outer instance of the object on the stack" and add tracking for it

Option #1 would probably lead to a bunch of new false positives. Option #2
is more precise and therefore better but requires more code.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231002/36060ec5/attachment.htm>

From mcimadamore at openjdk.org  Mon Oct  2 17:31:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 17:31:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <yfGlkLOlZrO1JNAkqS5mLbxmSBrrtIiOLipOGZEGLAU=.30779b79-78fa-43b7-8525-d03eaacd727d@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5052:

> 5050: 
> 5051:         return (source.isPrimitive() && target.isPrimitive()) &&
> 5052:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||

Does this mean that `byte` -> `char` is not exact? Aren't both integral types, thus invalidating `widening from one integral type to another` ?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4154:

> 4152:     public void visitTypeTest(JCInstanceOf tree) {
> 4153:         Type exprtype = attribExpr(tree.expr, env);
> 4154:         if(!allowPrimitivePatterns) {

nit: space missing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342954914
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342958314

From mcimadamore at openjdk.org  Mon Oct  2 17:37:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 17:37:06 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <Vjf1hBVtv8thvO7qhXAFDZbgP7Ek8mq7u55b4mIMOXE=.371c0a5a-5312-461e-9f38-0141c9010060@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 735:

> 733:                 }
> 734:             }
> 735:             if (tree.selector.type.hasTag(TypeTag.BOOLEAN)) {

I would have expected true/false to be treated more or less like enum constants when it came to exhaustiveness? E.g. boolean is similar to an enum type that only has two options (or, if you will, a sealed type with two permitted subtypes). So, IMHO the treatment for booleans should happen in the `exhausts` method - and this method should be left very simple (possibly unchanged?)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342970659

From mcimadamore at openjdk.org  Mon Oct  2 17:45:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 2 Oct 2023 17:45:21 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <dUbAZM12ZJjH18QccQi5NzNvxMIfks4f7SVHOOuZF6c=.bbcb6a1b-5afa-493a-a1e2-afa43f07e47f@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 770:

> 768:         PrimitiveGenerator primitiveGenerator = new PrimitiveGenerator();
> 769:         primitiveGenerator.assembleSig(primitiveType);
> 770:         return new Symbol.DynamicVarSymbol(names.fromString(primitiveGenerator.sb.toString()),

Why do we need a condy to generate a `Class` object for a type we know statically? E.g. will this not be resolved to <primitiveType>.class ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1342978008

From angelos.bimpoudis at oracle.com  Mon Oct  2 18:19:00 2023
From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis)
Date: Mon, 2 Oct 2023 18:19:00 +0000
Subject: RFR: 8314578: Non-verifiable code is emitted when two guards
 declare pattern variables in colon-switch
In-Reply-To: <50600388.10987511.1696259087551.JavaMail.zimbra@univ-eiffel.fr>
References: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
 <50600388.10987511.1696259087551.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <IA1PR10MB7515BA57AB8E612C1EB445BD82C5A@IA1PR10MB7515.namprd10.prod.outlook.com>

Hello R?mi,

https://github.com/openjdk/jdk/pull/15630/files#diff-06a9cd077d1cc0d23cc8810100b1ac02ac2a19904581f809bc79b49582971f69R35-R42

I added that pos test. I think this should compile ok (already did). Do I understand correctly?

Angelos.
________________________________
From: Remi Forax <forax at univ-mlv.fr>
Sent: 02 October 2023 17:04
To: Aggelos Biboudis <abimpoudis at openjdk.org>
Cc: compiler-dev <compiler-dev at openjdk.org>
Subject: Re: RFR: 8314578: Non-verifiable code is emitted when two guards declare pattern variables in colon-switch

----- Original Message -----
> From: "Aggelos Biboudis" <abimpoudis at openjdk.org>
> To: "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Monday, October 2, 2023 12:19:40 PM
> Subject: RFR: 8314578: Non-verifiable code is emitted when two guards declare pattern variables in colon-switch

> In the following example while the case pattern does not introduce binding
> variable, the guard does. `hasBindings` has been updated accordingly to accept
> any trees and check them if they contain a `visitBindingPattern`. Not only
> `JCPattern`'s.
>
>
> static void test(Object o) {
>    switch (o) {
>      case R1() when o instanceof String s:
>      case R2() when o instanceof Integer i:
>        System.out.println("hello: " + i);
>        break;
>      default:
>        break;
>    }
>  }

I think, i've fully understand the issue, what about

static void test(Object o) {
   switch (o) {
     case R1() when o instanceof String _:
     case R2() when o instanceof Integer _:
       System.out.println("hello: " + i);
       break;
     default:
       break;
   }
 }

regards,
R?mi

>
> -------------
>
> Commit messages:
> - 8314578: Non-verifiable code is emitted when two guards declare pattern
> variables in colon-switch
>
> Changes: https://git.openjdk.org/jdk/pull/15630/files
> Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15630&range=00
>  Issue: https://bugs.openjdk.org/browse/JDK-8314578
>  Stats: 41 lines in 3 files changed: 38 ins; 0 del; 3 mod
>  Patch: https://git.openjdk.org/jdk/pull/15630.diff
>  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15630/head:pull/15630
>
> PR: https://git.openjdk.org/jdk/pull/15630
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231002/d1d5e451/attachment.htm>

From vromero at openjdk.org  Mon Oct  2 19:51:23 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 2 Oct 2023 19:51:23 GMT
Subject: RFR: 8314578: Non-verifiable code is emitted when two guards
 declare pattern variables in colon-switch [v2]
In-Reply-To: <Tsvr_RFVZnesM_Q34qjTzyR17tO-wz5E5XV6QSNV0K8=.804585c7-7d75-4f4b-9e19-11926cde5ace@github.com>
References: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
 <Tsvr_RFVZnesM_Q34qjTzyR17tO-wz5E5XV6QSNV0K8=.804585c7-7d75-4f4b-9e19-11926cde5ace@github.com>
Message-ID: <A19EjKkErEsUDbXYRjh4uHgqAjKT8Icm8O_T8jvhcBw=.2a865f3d-2caf-451d-936a-c8a0c84c006a@github.com>

On Mon, 2 Oct 2023 16:07:56 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> In the following example while the case pattern does not introduce binding variable, the guard does. `hasBindings` has been updated accordingly to accept any trees and check them if they contain a `visitBindingPattern`. Not only `JCPattern`'s.
>> 
>> 
>> static void test(Object o) {
>>     switch (o) {
>>       case R1() when o instanceof String s:
>>       case R2() when o instanceof Integer i:
>>         System.out.println("hello: " + i);
>>         break;
>>       default:
>>         break;
>>     }
>>   }
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test with unnamed in guard

looks reasonable to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15630#pullrequestreview-1653389057

From acobbs at openjdk.org  Mon Oct  2 20:56:44 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 2 Oct 2023 20:56:44 GMT
Subject: Integrated: 8268622: Performance issues in javac `Name` class
In-Reply-To: <aFRsuubILSfwcPChu3GtRnL2H-kRkQicJpml9M9HIQ4=.dfca4fd6-43bc-428b-855c-1f20e948ca1d@github.com>
References: <aFRsuubILSfwcPChu3GtRnL2H-kRkQicJpml9M9HIQ4=.dfca4fd6-43bc-428b-855c-1f20e948ca1d@github.com>
Message-ID: <Vr9AfLdG8tHjw0TtkhE1sS0qi212k8CIvWGLetYZFwE=.ed2906ab-2c64-455d-bc2a-ef161a7f23c2@github.com>

On Tue, 29 Aug 2023 15:38:05 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Quoting [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622):
>> The javadoc team has identified performance issues in the javac `Name` class, particularly when it is used via its `CharSequence` interface ([JDK-8263321](https://bugs.openjdk.org/browse/JDK-8263321)). The main issue there is that the `CharSequence` is specifically character-oriented, whereas the native form inside javac is a byte[] in modified-UTF8 form. Operations like `.length()` and `.charAt(int)` have "simple" but very inefficient implementations.
> 
> Thanks to [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) we now have the option to swap in a `String`-based `Name` table implementation in place of the current UTF-8-based one. This does in fact improve performance of the compiler.
> 
> This patch does two things:
> * Make the `String`-based `Name` table implementation the default. The two other UTF-8-based implementations are still available via the flags `-XDuseUnsharedTable=true` and `-XDuseSharedTable=true` (the latter was the previous default). This results in a 19% speedup in my simple benchmark (see below).
> * Adds a new flag `-XDinternStringTable=true`, which turns on `intern()`ing of the `String`s in the `String` table. This however is **not** the default because it results in lower performance (see below). But it's possible this could help in other scenarios so it's left in there for future testing purposes.
> 
> Here are results from the [JavacNameTable.java](https://github.com/openjdk/jdk/files/12466359/JavacNameTable.java.txt) benchmark.
> 
> Benchmark                             Mode  Cnt   Score   Error  Units
> JavacNameTable.testSharedTable        avgt   25  54.145 ? 1.738  ms/op
> JavacNameTable.testStringTable        avgt   25  45.305 ? 0.415  ms/op
> JavacNameTable.testStringTableIntern  avgt   25  50.736 ? 0.245  ms/op
> JavacNameTable.testUnsharedTable      avgt   25  59.877 ? 2.503  ms/op
> 
> To reiterate: `testSharedTable` reflects the previous default; `testStringTable` reflects the new default. The other two options are available via the flags `-XDinternStringTable=true` and `-XDuseUnsharedTable=true`.

This pull request has now been integrated.

Changeset: 5c8366ee
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5c8366eea4555b5b145a5337e774020006e00db9
Stats:     18 lines in 2 files changed: 6 ins; 3 del; 9 mod

8268622: Performance issues in javac `Name` class

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/15470

From archie.cobbs at gmail.com  Tue Oct  3 02:44:23 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 2 Oct 2023 21:44:23 -0500
Subject: Escape this analysis does not consider anonymous class/local class
In-Reply-To: <CANSoFxsWdfepXGuquXFJDQwFD+Ebz+HcSdkTPXhKfg3KgqE2CA@mail.gmail.com>
References: <1418642090.10336306.1696230881758.JavaMail.zimbra@univ-eiffel.fr>
 <CANSoFxsWdfepXGuquXFJDQwFD+Ebz+HcSdkTPXhKfg3KgqE2CA@mail.gmail.com>
Message-ID: <CANSoFxsB7hr=UKmPB=3OdwAvE=dkGFx43gMu2ruFc9JcVohW3A@mail.gmail.com>

Hi Remi,

You got me curious.... it turns out it's not hard to fix those cases as
well as do a few other minor improvements.

I've created JDK-8317376 <https://bugs.openjdk.org/browse/JDK-8317376> to
track this.

-Archie

On Mon, Oct 2, 2023 at 12:30?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Hi Remi,
>
> On Mon, Oct 2, 2023 at 2:18?AM Remi Forax <forax at univ-mlv.fr> wrote:
>
>> The compiler does not emit a warning when the access to "this" is buried
>> inside an anonymous class
>>
>
> This is a known limitation. In summary, the analyzer tracks 'this'
> references that are outer instance references from the current instance,
> but it doesn't track 'this' references that are outer instance references
> from arbitrary objects on the stack.
>
> So when you say "new Inner()", the analyzer doesn't track the fact that
> the object on top of the stack now has a 'this' reference via its outer
> instance.
>
> This is one of the (many) trade-offs that were made between precision vs.
> code complexity.
>
> There are a couple of possible ways to address this:
>
>    1. Using existing reference types: record "new Inner()" as having an
>    indirect 'this' reference, and then update the logic for "Outer.this" to
>    pessimistically assume any indirect reference is an outer reference.
>    2. Add a new reference type: OuterExprRef to mean "a 'this' reference
>    from the outer instance of the object on the stack" and add tracking for it
>
> Option #1 would probably lead to a bunch of new false positives. Option #2
> is more precise and therefore better but requires more code.
>
> -Archie
>
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231002/0915c2c9/attachment.htm>

From asotona at openjdk.org  Tue Oct  3 07:40:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 07:40:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v8]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <pZj6SFj4l4XpuvZ1i6LuLKiWLBgPtl52ViAZHvvd-v0=.84cab210-f0f6-4f5c-bb66-3e4e4c7c1963@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/bd84bf93..8fd17c13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=06-07

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

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Tue Oct  3 08:29:03 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:29:03 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <ueYjUJ0DrAFhZ9s3vn8SJWZESdVKgODmkwKZoG52b5A=.c409500f-1472-468e-a154-5a7321df9abb@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <ueYjUJ0DrAFhZ9s3vn8SJWZESdVKgODmkwKZoG52b5A=.c409500f-1472-468e-a154-5a7321df9abb@github.com>
Message-ID: <qnYC8EhJXZs5pfLukSP_vDBQf9D5HCOsod1vqN9wU-o=.b7cfb0af-7c10-46d7-a60e-735e1fe04151@github.com>

On Mon, 2 Oct 2023 13:38:18 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/attribute/package-info.java line 27:
> 
>> 25: 
>> 26: /**
>> 27:  * <h2>Provides interfaces describing classfile attributes for the {@link java.lang.classfile} library.</h2>
> 
> Not 100% sure about the use of `h2` (here and elsewhere).

Header tags render nicely, do we have any other option?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1343707225

From asotona at openjdk.org  Tue Oct  3 08:42:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:42:59 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v9]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <0R0-mCGH8aqmuUN4jdIYvsEAliOdpIR31AeYRGSQCi0=.0adff479-1c7f-4a3e-9f6f-8928b7ab1eb2@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixing javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/8fd17c13..e5092a5f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=07-08

  Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Tue Oct  3 08:43:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:43:01 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
Message-ID: <vw8kUKurS5PJVKS6CDUcip3agMz1eQhtruaqGI0h2nw=.bf0f517e-ca8f-4903-9191-975925fd5b39@github.com>

On Mon, 2 Oct 2023 13:46:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java line 77:
> 
>> 75:      * A flags word, indicating the kind of range.  Multiple flag bits
>> 76:      * may be set.  Valid flags include
>> 77:      * {@link java.lang.classfile.ClassFile#CRT_STATEMENT},
> 
> Maybe it would be better to organize the links in a bullet list?

Yes, fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1343724213

From mcimadamore at openjdk.org  Tue Oct  3 08:45:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 08:45:27 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <dUbAZM12ZJjH18QccQi5NzNvxMIfks4f7SVHOOuZF6c=.bbcb6a1b-5afa-493a-a1e2-afa43f07e47f@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <dUbAZM12ZJjH18QccQi5NzNvxMIfks4f7SVHOOuZF6c=.bbcb6a1b-5afa-493a-a1e2-afa43f07e47f@github.com>
Message-ID: <AmCLLIprOSXbeYOBZt6YBXUhUOFtqDjq7u_Q5GcQxVM=.121befa6-57d9-420b-bee9-8e18e6761df4@github.com>

On Mon, 2 Oct 2023 17:42:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 770:
> 
>> 768:         PrimitiveGenerator primitiveGenerator = new PrimitiveGenerator();
>> 769:         primitiveGenerator.assembleSig(primitiveType);
>> 770:         return new Symbol.DynamicVarSymbol(names.fromString(primitiveGenerator.sb.toString()),
> 
> Why do we need a condy to generate a `Class` object for a type we know statically? E.g. will this not be resolved to <primitiveType>.class ?

Nevermind - you need a CP entry to a CONSTANT_Class, and you are dealing with primitive types, so you need the dynamic constant in order to create one (since we do not have CP forms for primitive class literals).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343732619

From asotona at openjdk.org  Tue Oct  3 08:47:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 08:47:02 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v10]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <HMyAWvy5rLb4ita6E1xwcOlJut3YMkPNX3TUGlBmZY4=.ce6845f8-af15-4484-ad65-1ee6a1ff7d3e@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/e5092a5f..5c834c7b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=08-09

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

PR: https://git.openjdk.org/jdk/pull/15706

From mcimadamore at openjdk.org  Tue Oct  3 08:58:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 08:58:00 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <zlcRgoJ6c2d_Q7Y1M9GGar-OVCrxcnaGe7gUb5JKLiU=.48589a40-d0fe-4655-b0b7-89e52401621d@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2929:

> 2927:             // This branch covers true unconditionality for the underlying type as well.
> 2928:             if (types.checkUnconditionallyExact(tree.expr.type, tree.pattern.type) &&
> 2929:                 !(tree.expr.type.isReference() && types.isExactPrimitiveWidening(types.unboxedType(tree.expr.type), tree.pattern.type))) {

Not super sure I get this line: if the expression type is unconditionally exact for the pattern type, shouldn't the test be always `true` ? What is the role of the extra guard after the `&&` ? Also, doesn't unconditionally exact implies that there is convertibility?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343750620

From mcimadamore at openjdk.org  Tue Oct  3 09:02:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:02:16 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <fcne-uFcuwFi8D3_C6SZ6Vm2QRv1LVdtY52f626Ie7w=.0c4be90d-5519-4111-9302-9ac0acbe0427@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:

> 2980:                     // =>
> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
> 2982:                     JCIdent argument = make.Ident(dollar_s);

In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343757201

From mcimadamore at openjdk.org  Tue Oct  3 09:08:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:08:05 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <fcne-uFcuwFi8D3_C6SZ6Vm2QRv1LVdtY52f626Ie7w=.0c4be90d-5519-4111-9302-9ac0acbe0427@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <fcne-uFcuwFi8D3_C6SZ6Vm2QRv1LVdtY52f626Ie7w=.0c4be90d-5519-4111-9302-9ac0acbe0427@github.com>
Message-ID: <HavdMPItNJNFegZnxo_oq95yrBJ4jYljtfE3IkNQzMk=.e4389ce7-0909-488b-b498-6ec2cb29e919@github.com>

On Tue, 3 Oct 2023 08:58:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:
> 
>> 2980:                     // =>
>> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
>> 2982:                     JCIdent argument = make.Ident(dollar_s);
> 
> In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)

Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.

I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).

Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.

In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.

While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343767531

From mcimadamore at openjdk.org  Tue Oct  3 09:11:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:11:31 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <n7BRe-KOvAqgszEVLd-SwQ-oIabSlnDhAez9BzYRocw=.6002fac7-6b80-4fca-a198-bd843c23e58c@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3001:

> 2999:     }
> 3000: 
> 3001:     static class TypePairs {

I believe this could be a record between two TypeSymbols? Then you could have an additional constructor that takes two types and retrieves their `tsym` and call the canonical constructor (and then you can drop equals/hashcode).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343772445

From mcimadamore at openjdk.org  Tue Oct  3 09:16:31 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 09:16:31 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <Ktk1U2NQRQd1JhG1aJbJzLclZfmKikWaqKCGkng8W8U=.f9066e12-3846-43fc-ae58-5496d9edc96e@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 494:

> 492:                                                                     syms.classType.tsym)));
> 493: 
> 494:             // The boolean flag `hasUnconditionalPattern` is true when either there

A it surprised that something has changed here - can you expand?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343778940

From mcimadamore at openjdk.org  Tue Oct  3 10:00:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 10:00:48 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
Message-ID: <ZWs9yJPMLWqRX4l9DNbolMFm-quV16mjnsqYmGFUecI=.ca2e2480-bccb-400c-81af-e8f9ee1bc4e3@github.com>

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into primitive-patterns
>  - Implement type pairs to exactnessMethod name
>  - Apply suggestions from code review
>    
>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 228:

> 226:                         currentTest = trueDef;
> 227:                     } else if (currentLabelClass.isPrimitive()) {
> 228:                          if (selectorType.isInstance(Object.class)) {

As discussed offline, I believe this is wrong, and it should be replaced by `Class::equals`. That said, I think that "accidentally" you get the desired behavior here, as demonstrated by jshell:


jshell> Byte.class.isInstance(Object.class)
$6 ==> false


jshell> Object.class.isInstance(Object.class)
$8 ==> true


So, this effectively acts as a test to check if the selector type is `Object`. Of course, since `isInstance` is used, spurious stuff is picked up as well:


jshell> Class.class.isInstance(Object.class)
$7 ==> true

But this situation turns out to be non problematic, given that a primitive pattern is not applicable to a selector type Class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1343840181

From mcimadamore at openjdk.org  Tue Oct  3 10:09:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 10:09:11 GMT
Subject: RFR: 8316971: Add Lint warning for restricted method calls [v4]
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <edZdGYmiB4G_HJGAtJim-EW-A1wTQD7bdeIlRmTlYuI=.4e8d978b-c31c-4341-925e-7a572f50cf2a@github.com>

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add comment in jdk.compiler's module-info

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15964/files
  - new: https://git.openjdk.org/jdk/pull/15964/files/1951b742..1751bef3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15964&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/15964

From asotona at openjdk.org  Tue Oct  3 12:47:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 12:47:48 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <lS0_dNEGO8_t4Dvc1dNw8Jmgq3NoJ5kep8SKdZ-O2yk=.f62606d2-eb3a-4f60-82a4-d3d6754c261f@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
 <lS0_dNEGO8_t4Dvc1dNw8Jmgq3NoJ5kep8SKdZ-O2yk=.f62606d2-eb3a-4f60-82a4-d3d6754c261f@github.com>
Message-ID: <pacU_MDzNKwe0SuGUP_N7t9leVDmMmLE3CEbwvqmYGo=.0b2bdcfb-cdce-4d37-9a0e-58ffc4bb57ba@github.com>

On Mon, 2 Oct 2023 13:50:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 67:
>> 
>>> 65: 
>>> 66:     /**
>>> 67:      * {@return for an {@code invokeinterface}, the {@code count} value, as defined in {@jvms 6.5}}
>> 
>> Suggestion:
>> 
>>      * {@return the {@code count} value of an {@code invokeinterface} instruction, as defined in {@jvms 6.5}}
>
> What does this return for something that is not `invokeinterface` ? Do we infer the count from the descriptor? Or do we return -1 ? This should probably be reflected in the javadoc.

Return value for other invoke instructions was inconsistent across implementations.
I've unified them to return 0 and mentioned it in the javadoc.
Thanks for pointing it out, good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344039936

From asotona at openjdk.org  Tue Oct  3 12:53:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 12:53:50 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
Message-ID: <7gLBfvrwDWY6W3X-ETNeiN5Glv3Ol3ykwjzqNBUVv3c=.f948789b-d2bf-4a8e-ae84-d9c1f58a8207@github.com>

On Mon, 2 Oct 2023 13:57:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 273:
> 
>> 271:  * <p>
>> 272:  * More complex verification of a classfile can be achieved by explicit invocation
>> 273:  * of {@link java.lang.classfile.ClassModel#verify}.
> 
> Aren't part of verification also ran as part of generating stackmaps (unless stackmap inference is disabled) ? Should it be mentioned here?

Only fragment of verification conditions are required for stackmaps generator and it is indirectly mentioned in the sentence: "However fatal inconsistencies (like for example invalid code sequence or unresolved labels) affects internal tools and may cause exceptions later in the classfile building process."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344048341

From abimpoudis at openjdk.org  Tue Oct  3 13:28:20 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Oct 2023 13:28:20 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v4]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <akwHI3rONUUahQKZsByBXU40d8cWyzil3t4jnWkqoso=.afed3aba-49c0-4d57-b073-bfb782031192@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix exhausts and equals in SwitchBootstraps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ad6071b0..d356b36f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=02-03

  Stats: 54 lines in 3 files changed: 16 ins; 24 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Tue Oct  3 13:28:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 3 Oct 2023 13:28:29 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <ZWs9yJPMLWqRX4l9DNbolMFm-quV16mjnsqYmGFUecI=.ca2e2480-bccb-400c-81af-e8f9ee1bc4e3@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <ZWs9yJPMLWqRX4l9DNbolMFm-quV16mjnsqYmGFUecI=.ca2e2480-bccb-400c-81af-e8f9ee1bc4e3@github.com>
Message-ID: <HQ0zoRvGG9uexuwmMc01XPlIQ7D-VZvj-8QII8x8DzU=.7ab75301-427d-4451-9e5a-a23ecb59c3e2@github.com>

On Tue, 3 Oct 2023 09:58:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 228:
> 
>> 226:                         currentTest = trueDef;
>> 227:                     } else if (currentLabelClass.isPrimitive()) {
>> 228:                          if (selectorType.isInstance(Object.class)) {
> 
> As discussed offline, I believe this is wrong, and it should be replaced by `Class::equals`. That said, I think that "accidentally" you get the desired behavior here, as demonstrated by jshell:
> 
> 
> jshell> Byte.class.isInstance(Object.class)
> $6 ==> false
> 
> 
> jshell> Object.class.isInstance(Object.class)
> $8 ==> true
> 
> 
> So, this effectively acts as a test to check if the selector type is `Object`. Of course, since `isInstance` is used, spurious stuff is picked up as well:
> 
> 
> jshell> Class.class.isInstance(Object.class)
> $7 ==> true
> 
> But this situation turns out to be non problematic, given that a primitive pattern is not applicable to a selector type Class.

Fixed as well.

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5052:
> 
>> 5050: 
>> 5051:         return (source.isPrimitive() && target.isPrimitive()) &&
>> 5052:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
> 
> Does this mean that `byte` -> `char` is not exact? Aren't both integral types, thus invalidating `widening from one integral type to another` ?

Indeed it is not unconditionally exact. byte to char combines both widening and narrowing primitive conversions 

https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.4

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 4154:
> 
>> 4152:     public void visitTypeTest(JCInstanceOf tree) {
>> 4153:         Type exprtype = attribExpr(tree.expr, env);
>> 4154:         if(!allowPrimitivePatterns) {
> 
> nit: space missing

Fixed!

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 735:
> 
>> 733:                 }
>> 734:             }
>> 735:             if (tree.selector.type.hasTag(TypeTag.BOOLEAN)) {
> 
> I would have expected true/false to be treated more or less like enum constants when it came to exhaustiveness? E.g. boolean is similar to an enum type that only has two options (or, if you will, a sealed type with two permitted subtypes). So, IMHO the treatment for booleans should happen in the `exhausts` method - and this method should be left very simple (possibly unchanged?)

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344099605
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344095080
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344095209
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344095335

From asotona at openjdk.org  Tue Oct  3 13:43:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 13:43:47 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <cwxUenwfLme41U7fkP6nFbeoSnW8rGOEtRatYq7dxWk=.5169026f-5939-494b-a79b-302197607a30@github.com>
Message-ID: <JGjt6tnykmijofxutmmS8RoY-u0WKb6NZdfiRZpcUWM=.bcea9edf-2e34-4e0a-a9f2-a94792f86a55@github.com>

On Mon, 2 Oct 2023 13:54:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 259:
> 
>> 257:  * the classfile building process.
>> 258:  * <p>
>> 259:  * Basic syntax control can be achieved using symbolic descriptors. For example
> 
> What does "syntax control" mean? The concept is used, but not defined, in the javadoc. (I presume we mean eg.g. turning String into `Ljava/lang/String;`)

I've reformulated and extended the paragraph a bit and added another snippet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344126800

From asotona at openjdk.org  Tue Oct  3 14:03:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 14:03:54 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>
Message-ID: <P8Y12FbLwDAw2yOd9DxxQjLCVqxGesozmInXEFsUs7I=.2f787a2a-5e52-44c8-bca4-0bda4975f39a@github.com>

On Mon, 2 Oct 2023 14:03:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 389:
> 
>> 387:  * To achieve stability of transformations in future JDK releases it is desired
>> 388:  * to set appropriate response to potential new classfile elements appearing.
>> 389:  * Transformation designed to handle all situation should be implemented strict way,
> 
> "handle all situations" - I couldn't make much sense of it. I only got it when reading the text that follows, which says "transformation selectively interested in ...". This para should be rephrased for better clarity. E.g.
> "Classfile transforms that are interested in consuming _all_ classfile elements should be implemented in a strict fashion, so that new exceptions will be issued, should a new and unknown classfile element appear ... Conversely, classfile transforms that are only interested in consuming a portion of classfile elements do not need to concern with new and unknown classfile elements ... because ... "

Thanks for the review, I've reformulated the paragraph as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344157870

From asotona at openjdk.org  Tue Oct  3 14:11:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 14:11:08 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v11]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <Cehtoo5a5hCCfgy5wMfgUyjCcXtCKDVgytQRomw12Wk=.d95b0ae5-68a4-476a-a1fe-fe3f6b33de40@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:

 - fixed case in the test text
 - fixing javadoc
 - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/5c834c7b..c1d95488

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=09-10

  Stats: 42 lines in 5 files changed: 21 ins; 0 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Tue Oct  3 14:11:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 3 Oct 2023 14:11:11 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v3]
In-Reply-To: <XtmZAh2PhGzdtRLkpxTjVZev7NAY4g2z1et6CdSOTCM=.3e70de2d-b267-4de0-b95a-90c847dd10ce@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <CWoXzT4X4XuP8kN7e9DUangstiBi18UBkjc1jjOYIMY=.82ed246b-2af5-4134-9394-4568b89166a6@github.com>
 <XtmZAh2PhGzdtRLkpxTjVZev7NAY4g2z1et6CdSOTCM=.3e70de2d-b267-4de0-b95a-90c847dd10ce@github.com>
Message-ID: <hL7ZLwFNAIdDe6Mlg-Z07Rn-mN3NqfI312pfedforp8=.5c0d8e86-13b7-4233-afad-585214a93315@github.com>

On Mon, 2 Oct 2023 14:51:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc typo
>
> test/langtools/tools/javac/classfiles/attributes/SourceFile/NoSourceFileAttribute.java line 52:
> 
>> 50:         assertNull(
>> 51:                 ClassFile.of().parse(getClassFile(NoSourceFileAttribute.class).toPath()).findAttribute(Attributes.SOURCE_FILE).orElse(null),
>> 52:                 "ClassFile should have no SourceFile attribute when compiled without debug information.");
> 
> Not sure if replacing the camel case ClassFile in the assertion message is what you wanted here

Nice catch, fixed, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344165330

From mcimadamore at openjdk.org  Tue Oct  3 15:00:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 3 Oct 2023 15:00:36 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <HQ0zoRvGG9uexuwmMc01XPlIQ7D-VZvj-8QII8x8DzU=.7ab75301-427d-4451-9e5a-a23ecb59c3e2@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <ZWs9yJPMLWqRX4l9DNbolMFm-quV16mjnsqYmGFUecI=.ca2e2480-bccb-400c-81af-e8f9ee1bc4e3@github.com>
 <HQ0zoRvGG9uexuwmMc01XPlIQ7D-VZvj-8QII8x8DzU=.7ab75301-427d-4451-9e5a-a23ecb59c3e2@github.com>
Message-ID: <-L0VbUtNh5kdKGoUdONyiIF2RjKislGhtUcoF7ACONI=.8b7b9a17-4659-49ed-9ea9-dce41381a7b5@github.com>

On Tue, 3 Oct 2023 13:19:18 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5052:
>> 
>>> 5050: 
>>> 5051:         return (source.isPrimitive() && target.isPrimitive()) &&
>>> 5052:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
>> 
>> Does this mean that `byte` -> `char` is not exact? Aren't both integral types, thus invalidating `widening from one integral type to another` ?
>
> Indeed it is not unconditionally exact. byte to char combines both widening and narrowing primitive conversions 
> 
> https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.4

Ha! Of course - the problem is not the definition of "integral type" (which includes `char`), but the fact that there's no widening from `byte` to `char`. I agree that the code (and the spec changes) do the right thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1344261063

From mark.reinhold at oracle.com  Tue Oct  3 15:25:48 2023
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Tue, 3 Oct 2023 15:25:48 +0000
Subject: New candidate JEP: 458: Launch Multi-File Source-Code Programs
Message-ID: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>

https://openjdk.org/jeps/458

  Summary: Enhance the java application launcher to be able to run a
  program supplied as multiple files of Java source code. This will
  make the transition from small programs to larger ones more gradual,
  enabling developers to choose whether and when to go to the trouble of
  configuring a build tool.

- Mark

From davidalayachew at gmail.com  Tue Oct  3 16:28:03 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 3 Oct 2023 12:28:03 -0400
Subject: New candidate JEP: 458: Launch Multi-File Source-Code Programs
In-Reply-To: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>
References: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>
Message-ID: <CAA9v-_OuSW1v6HoObRMYF4850No4+kq9_Pw++Lk672ERaPd8uA@mail.gmail.com>

Hello Mark,

Thank you very much for sending this!

This will be a god-send for those of us on the tutoring side. Being able to
just "java YourCode.java" makes things so much easier to teach the
students. Every time I am with them and we get to the point of refactoring,
they always have a terrible experience because, and I quote, "It feels like
breaking things up just makes it more complicated for no reason".

Trying to instill good habits is frustrating for them because the level of
effort to do the best long term thing is much higher than just stuffing it
all into a file that's >1k lines long. Limiting the change to just sticking
it in the new class (file), then calling that class makes the abstraction
that much more seamless. It also will have a big benefit for me in my every
day programming as well.

Thank you all for putting this together!
David Alayachew

On Tue, Oct 3, 2023 at 11:46?AM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> https://openjdk.org/jeps/458
>
>   Summary: Enhance the java application launcher to be able to run a
>   program supplied as multiple files of Java source code. This will
>   make the transition from small programs to larger ones more gradual,
>   enabling developers to choose whether and when to go to the trouble of
>   configuring a build tool.
>
> - Mark
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231003/af563c95/attachment.htm>

From acobbs at openjdk.org  Tue Oct  3 18:17:07 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Oct 2023 18:17:07 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
 [v2]
In-Reply-To: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
Message-ID: <hEPdWLZ49XCkqyUXCzY0jMpeZds0MKJUXrQYosBPcAQ=.baa2275d-b24b-44f5-b311-545e532991db@github.com>

> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
> 
> This patch relaxes this invariant check to allow for this case.
> 
> This also fixes another variant of the same bug caused by certain enhanced `for()` loops.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add fix and unit test for another variant of the assertion failure.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16001/files
  - new: https://git.openjdk.org/jdk/pull/16001/files/8ad1247a..03cda07e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=00-01

  Stats: 21 lines in 2 files changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16001/head:pull/16001

PR: https://git.openjdk.org/jdk/pull/16001

From duke at openjdk.org  Tue Oct  3 18:59:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 3 Oct 2023 18:59:23 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v11]
In-Reply-To: <Cehtoo5a5hCCfgy5wMfgUyjCcXtCKDVgytQRomw12Wk=.d95b0ae5-68a4-476a-a1fe-fe3f6b33de40@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <Cehtoo5a5hCCfgy5wMfgUyjCcXtCKDVgytQRomw12Wk=.d95b0ae5-68a4-476a-a1fe-fe3f6b33de40@github.com>
Message-ID: <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>

On Tue, 3 Oct 2023 14:11:08 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - fixed case in the test text
>  - fixing javadoc
>  - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter

src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java line 299:

> 297:         }
> 298:         maxStringLength = currentMaxStringLength;
> 299:         // The ClassFile's access_flags field is just after the last constant pool entry.

This?has nothing to?do?with the?`ClassFile`?API
Suggestion:

        // The Classfile's access_flags field is just after the last constant pool entry.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1344576036

From acobbs at openjdk.org  Tue Oct  3 19:05:23 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Oct 2023 19:05:23 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
 [v3]
In-Reply-To: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
Message-ID: <d5lAYt3y0nFrblKldOslAPQLd-rSOajd1OjwtnQmwbQ=.30242f73-6b96-4653-8b80-535fe4bc0cca@github.com>

> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
> 
> This patch explicitly clears any leftover `ExprRef`'s after evaluating a lambda body; this restores the asserted invariant when the lambda body is an expression.
> 
> This also fixes another variant of the same bug caused by certain enhanced `for()` loops. In this case, the leftover `ExprRef` was from evaluating the loop expression. This was just a side-effect of the analyzer failing to override `TreeScanner` to actually assign the loop expression to the loop variable.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Replace 8ad1247a with more correct fix.
  
  The mistaken assumption was that a lambda body is always a JCBlock.
  It can also be a JCExpression, in which case it could result in an
  ExprRef 'this' reference.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16001/files
  - new: https://git.openjdk.org/jdk/pull/16001/files/03cda07e..457bcca6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=01-02

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

PR: https://git.openjdk.org/jdk/pull/16001

From attila.kelemen85 at gmail.com  Tue Oct  3 19:10:44 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Tue, 3 Oct 2023 21:10:44 +0200
Subject: New candidate JEP: 458: Launch Multi-File Source-Code Programs
In-Reply-To: <4c474c61-9a3e-4eb2-9405-c7bcd55a81e7@Spark>
References: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>
 <4c474c61-9a3e-4eb2-9405-c7bcd55a81e7@Spark>
Message-ID: <CAKDaPBfCcbENmuSRPSzyk5YEtoN6+p0WUBb4J=rZQcnxT7963Q@mail.gmail.com>

I don't think that fear is warranted, because you have to package any
non-trivial application anyway, in which case you will have some kind of
build (not to mention that compiling it has obvious benefits anyway). And
if somebody wants to use it in a home project for his/her own purpose, then
I don't see anything wrong with that. As far as I can see this just opens
up some extra possibilities, if you want to leave some code editable after
deployment (for the same reason you might want a single file).

CC <4evnyuij at gmail.com> ezt ?rta (id?pont: 2023. okt. 3., K, 17:36):

> Hi,
>
> I?m not sure if the advantage of launching several source files will
> encourage even using a build tool at all. A beginner might see this feature
> given to them as something to make their beginning steps easier, but why
> switch at that point? The mechanism compiles everything for them when
> needed, and libraries can be specified over the classpath anyway. Why
> switch to a proper build tool?
>
> I find the limitation of a single source file to be quite good, as it
> encourages using the appropriate technology for creating larger scale
> applications.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231003/a106c91c/attachment.htm>

From acobbs at openjdk.org  Tue Oct  3 21:46:50 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 3 Oct 2023 21:46:50 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
 [v4]
In-Reply-To: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
Message-ID: <dJgPIFXLB1s_a8ut_PNTbiOTlWSI94JN_pMZ9CcdbhY=.fe50b7a9-30d6-438d-a81a-75a097ecdffb@github.com>

> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
> 
> This patch explicitly clears any leftover `ExprRef`'s after evaluating a lambda body; this restores the asserted invariant when the lambda body is an expression.
> 
> This also fixes another variant of the same bug caused by certain enhanced `for()` loops. In this case, the leftover `ExprRef` was from evaluating the loop expression. This was just a side-effect of the analyzer failing to override `TreeScanner` to actually assign the loop expression to the loop variable.

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

 - Merge branch 'master' into JDK-8317336
 - Replace 8ad1247a with more correct fix.
   
   The mistaken assumption was that a lambda body is always a JCBlock.
   It can also be a JCExpression, in which case it could result in an
   ExprRef 'this' reference.
 - Add fix and unit test for another variant of the assertion failure.
 - Fix incorrect invariant assertion in this escape analysis.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16001/files
  - new: https://git.openjdk.org/jdk/pull/16001/files/457bcca6..09e42837

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=02-03

  Stats: 6519 lines in 237 files changed: 2427 ins; 1294 del; 2798 mod
  Patch: https://git.openjdk.org/jdk/pull/16001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16001/head:pull/16001

PR: https://git.openjdk.org/jdk/pull/16001

From davidalayachew at gmail.com  Tue Oct  3 21:54:29 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 3 Oct 2023 17:54:29 -0400
Subject: New candidate JEP: 458: Launch Multi-File Source-Code Programs
In-Reply-To: <CAKDaPBfCcbENmuSRPSzyk5YEtoN6+p0WUBb4J=rZQcnxT7963Q@mail.gmail.com>
References: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>
 <4c474c61-9a3e-4eb2-9405-c7bcd55a81e7@Spark>
 <CAKDaPBfCcbENmuSRPSzyk5YEtoN6+p0WUBb4J=rZQcnxT7963Q@mail.gmail.com>
Message-ID: <CAA9v-_OTXJNtSQ9FyAJo5r5vUkOSQks2qDZ10hKmhAc-xMVOdQ@mail.gmail.com>

Hello Attila,

Good response! I can further address this.

I think that the person that you are responding to raises a good point --
at first glance, this JEP seems to address the problem exhaustively -- just
find the Main.java, and all classes that it depends upon should get
compiled. You may need to add a few files/directories/regexes-like-*.java
onto that list, but it should be fine, right? Why do we need a build tool
after all? This strategy can scale pretty far.

The reason why a build tool is important and valuable to include is because
a build tool handles the work of letting 2 codebases work together when
they can't just point to each other's "latest version". If Project A is on
V14 and depends on V6 of Project B, but Project B is on V22, you don't want
to try touching that sort of effort WITHOUT a build tool. That would get
ugly VERY FAST.

It is this problem that a build tool was created to solve -- it allows
projects to depend on other projects without conforming to each other's
build tempo. Project B can pump out features as fast as it wants to, but as
long as V6 of Project B is available to Project A, then B and A are not
slowing each other down. THAT is what a build tool gives you. It allows you
to easily specify and grab V6 of Project B. And more specifically, Project
A can catch up to Project B at their own tempo, if they ever even do. This
"gradual migration" should be very familiar to Java developers who were
around for Java 5's generics and Java 8's lambdas.

This JEP (and really, Java in general) does not attempt to solve this
problem. This versioning and organization problem is left firmly in the
courts of build tools. A build tool does the work of gathering and
organizing THE CORRECT VERSIONS of each dependency. But once that is down,
Java (facilitates and enables) efficiently compiling and running the
pre-gathered and organized sources.

So, a project that does not (and won't soon need to) care about dependency
versioning likely doesn't need a build tool at all. Or more specifically,
unless there is a significant or frequent amount of dependency version
management, you can get by without a build tool just fine. But once you
need to manage that problem at scale, a build tool is the proper solution.

The only other reason to have a build tool is if other projects will want
to have YOUR PROJECT as a dependency. They are usually already depending on
a build tool, and thus, the most convenient way for them to grab your
dependency is by having your dependency be in the build ecosystem. The most
convenient solution (for them) is for you to configure your project to use
the mentioned build tool, so that your project is easy to add as a
dependency.

That said (ending on a provocative note lol), I am *1000000% onboard for
the idea of Java entering into the build tool world and offering their own
build tool*. I don't like any of the existing options and I think Java
would do a way better job of supporting this. Modules feel like a tacked on
after thought for most of these build tools, whereas Java themselves make
it feel like a first class feature that was there from the beginning. I
feel like if Java tried, they could soundly beat all these other tools and
offer a great solution that would do a way better job of feeding the
ecosystem over what currently exists. If only it was worth the effort :/

Thank you for your time!
David Alayachew

On Tue, Oct 3, 2023 at 3:11?PM Attila Kelemen <attila.kelemen85 at gmail.com>
wrote:

> I don't think that fear is warranted, because you have to package any
> non-trivial application anyway, in which case you will have some kind of
> build (not to mention that compiling it has obvious benefits anyway). And
> if somebody wants to use it in a home project for his/her own purpose, then
> I don't see anything wrong with that. As far as I can see this just opens
> up some extra possibilities, if you want to leave some code editable after
> deployment (for the same reason you might want a single file).
>
> CC <4evnyuij at gmail.com> ezt ?rta (id?pont: 2023. okt. 3., K, 17:36):
>
>> Hi,
>>
>> I?m not sure if the advantage of launching several source files will
>> encourage even using a build tool at all. A beginner might see this feature
>> given to them as something to make their beginning steps easier, but why
>> switch at that point? The mechanism compiles everything for them when
>> needed, and libraries can be specified over the classpath anyway. Why
>> switch to a proper build tool?
>>
>> I find the limitation of a single source file to be quite good, as it
>> encourages using the appropriate technology for creating larger scale
>> applications.
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231003/8e9c393c/attachment.htm>

From darcy at openjdk.org  Wed Oct  4 03:35:34 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 4 Oct 2023 03:35:34 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v3]
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <-SlIUcRXSIkBogaCBr_7pPE859JsA76i_4lFz6Rdt4o=.d23eb6cc-3e41-4b83-b4f9-5ddd5c589e88@github.com>

> Change annotation processing to be opt-in rather than opt-out.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - Updates for a clean test run.
 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - JDK-8306819: Consider disabling the compiler's default active annotation processing

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

Changes: https://git.openjdk.org/jdk/pull/14432/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=02
  Stats: 53 lines in 5 files changed: 17 ins; 8 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/14432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14432/head:pull/14432

PR: https://git.openjdk.org/jdk/pull/14432

From asotona at openjdk.org  Wed Oct  4 05:35:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 05:35:49 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v12]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <bckev0onQFlcOPJBdvXvt52GhJEqObnQGpELZjBuiIo=.c8315e7d-554b-4a3b-8c99-0066132f7653@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
  
  Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/c1d95488..859afe81

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=10-11

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

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Wed Oct  4 05:35:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 05:35:52 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v11]
In-Reply-To: <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <Cehtoo5a5hCCfgy5wMfgUyjCcXtCKDVgytQRomw12Wk=.d95b0ae5-68a4-476a-a1fe-fe3f6b33de40@github.com>
 <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>
Message-ID: <21Ioc75aRIQsnmIWOa4YoMTofa0rqdiEH80vjhutsOo=.0f51e3b3-fac3-4a9e-9827-53f9566a9b82@github.com>

On Tue, 3 Oct 2023 18:55:36 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - fixed case in the test text
>>  - fixing javadoc
>>  - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter
>
> src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java line 299:
> 
>> 297:         }
>> 298:         maxStringLength = currentMaxStringLength;
>> 299:         // The ClassFile's access_flags field is just after the last constant pool entry.
> 
> This?has nothing to?do?with the?`ClassFile`?API
> Suggestion:
> 
>         // The Classfile's access_flags field is just after the last constant pool entry.

Thanks for catching it, the refactoring was a bit more aggressive than expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1345214426

From asotona at openjdk.org  Wed Oct  4 09:09:34 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 09:09:34 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v13]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <0e7ss_3aiu_Su7Aam9NQVNpY4sk32g6_4vP64PqmzvM=.91abde8c-0e66-46b4-86e6-77ef95b6a55d@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 336 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - Update src/java.base/share/classes/jdk/internal/org/objectweb/asm/ClassReader.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - fixed case in the test text
 - fixing javadoc
 - Unified implementations of InvokeInstruction::count, fixed javadoc and javap CodeWriter
 - Update src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - fixing javadoc
 - fixing javadoc
 - fixing javadoc
 - Apply suggestions from code review
   
   Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>
 - ... and 326 more: https://git.openjdk.org/jdk/compare/d4c904d8...ef2305d8

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=12
  Stats: 29011 lines in 759 files changed: 13016 ins; 12505 del; 3490 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From abimpoudis at openjdk.org  Wed Oct  4 09:26:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 09:26:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v5]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <rtnDXjSxxrgdvSW_w6pvVslxhyN3V6U1TzHY-SAjmqg=.edbe6c68-c1d6-4634-ad1e-9d948cd5a3e6@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary disambiguation in TransPatterns and simplify Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/d356b36f..f036fdbc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=03-04

  Stats: 21 lines in 3 files changed: 0 ins; 15 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From asotona at openjdk.org  Wed Oct  4 09:30:16 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 4 Oct 2023 09:30:16 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed hotspot test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/ef2305d8..a6a73b37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=12-13

  Stats: 13 lines in 1 file changed: 1 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From mcimadamore at openjdk.org  Wed Oct  4 09:39:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Oct 2023 09:39:50 GMT
Subject: Integrated: 8316971: Add Lint warning for restricted method calls
In-Reply-To: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
References: <MCK5PF555m_khiWbuTq64mR5r2HioTbSTtNropxsSd0=.3114ae03-5872-42f2-82f8-acc0da4b3fd4@github.com>
Message-ID: <rO95HphnEL4C0m2lF-myfK0nQB7Pj5aC1Y1A9eynRDc=.4c72279b-6504-4098-b8c3-48c0a112d422@github.com>

On Thu, 28 Sep 2023 13:13:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds a new lint warning category, namely `-Xlint:restricted` to enable warnings on restricted method calls.
> 
> The patch is relatively straightforward: javac marks methods that are marked with the `@Restricted` annotation with a corresponding internal flag. This is done both in `Annotate` when compiling JDK from source, and in `ClassReader` when JDK classfiles are read. When calls to methods marked with the special flag are found, a new warning is issued.
> 
> While there are some similarities between this new warning and the preview API warnings, the compiler does *not* emit a mandatory note when a compilation unit is found to have one or more restricted method calls. In other words, this is just a plain lint warning.
> 
> The output from javac looks as follows:
> 
> 
> Foo.java:6: warning: [restricted] MemorySegment.reinterpret(long) is a restricted method.
>       Arena.ofAuto().allocate(10).reinterpret(100);
>                                  ^
>   (Restricted methods are unsafe, and, if used incorrectly, they might crash the JVM or result in memory corruption)

This pull request has now been integrated.

Changeset: 0d4de8a7
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d4de8a71f063e44618f43ddd862a91aed647f48
Stats:     119 lines in 15 files changed: 115 ins; 0 del; 4 mod

8316971: Add Lint warning for restricted method calls

Reviewed-by: ihse, vromero

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

PR: https://git.openjdk.org/jdk/pull/15964

From abimpoudis at openjdk.org  Wed Oct  4 10:02:39 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:02:39 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v6]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <xjXrS301QRgaKm6MFAWs1oF2g1JFfzsfg3zWZSjSx8Q=.d53f2b8f-46aa-48c1-ac71-a9e803208758@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Rename exactness methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/f036fdbc..1d88baaf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=04-05

  Stats: 76 lines in 3 files changed: 0 ins; 0 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Wed Oct  4 10:02:44 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:02:44 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <Ktk1U2NQRQd1JhG1aJbJzLclZfmKikWaqKCGkng8W8U=.f9066e12-3846-43fc-ae58-5496d9edc96e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <Ktk1U2NQRQd1JhG1aJbJzLclZfmKikWaqKCGkng8W8U=.f9066e12-3846-43fc-ae58-5496d9edc96e@github.com>
Message-ID: <VU4P8oi0ZN_2wwVc1Y3JRhW7quQawVaPX8Vhmd4mVQc=.01ac8870-2ecb-4718-a28a-8dadc0feda2c@github.com>

On Tue, 3 Oct 2023 09:13:30 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 494:
> 
>> 492:                                                                     syms.classType.tsym)));
>> 493: 
>> 494:             // The boolean flag `hasUnconditionalPattern` is true when either there
> 
> A it surprised that something has changed here - can you expand?

Indeed that was not needed anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1345531726

From abimpoudis at openjdk.org  Wed Oct  4 10:13:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:13:40 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v7]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <dq_kuAFtJZfuupSCDUfswqzS2Ov3naXBxjvMJBBOc9U=.1a4a5d93-d7a4-49f0-a283-8f5709d83b1d@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Simplify TypePairs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/1d88baaf..ef98c040

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=05-06

  Stats: 49 lines in 2 files changed: 0 ins; 44 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Wed Oct  4 10:13:43 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 4 Oct 2023 10:13:43 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <n7BRe-KOvAqgszEVLd-SwQ-oIabSlnDhAez9BzYRocw=.6002fac7-6b80-4fca-a198-bd843c23e58c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <n7BRe-KOvAqgszEVLd-SwQ-oIabSlnDhAez9BzYRocw=.6002fac7-6b80-4fca-a198-bd843c23e58c@github.com>
Message-ID: <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>

On Tue, 3 Oct 2023 09:08:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3001:
> 
>> 2999:     }
>> 3000: 
>> 3001:     static class TypePairs {
> 
> I believe this could be a record between two TypeSymbols? Then you could have an additional constructor that takes two types and retrieves their `tsym` and call the canonical constructor (and then you can drop equals/hashcode).

Done and simplified https://github.com/openjdk/jdk/pull/15638/commits/ef98c040c909981077936c6ff4280b6da04b8c24. Do you think we can simplify further (or benefit at all) by also eliminating duplication between SwitchBootstrap and Lower?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1345545796

From mchung at openjdk.org  Wed Oct  4 21:43:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 4 Oct 2023 21:43:26 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>
Message-ID: <unW6bXMb6qwz0xS6NTsXMhHV9jc84l7jYSvn0RWA-DQ=.bcb5767f-5d5f-4240-b793-ce0e266103ca@github.com>

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed hotspot test

Marked as reviewed by mchung (Reviewer).

I reviewed java.base, jlink, jdeps, jartool source and test changes except the Class-File API and implementation (i.e. `java/lang/classfile/**` and `jdk/internal/classfile/**`).

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

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1658532577
PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1747681315

From vromero at openjdk.org  Wed Oct  4 22:18:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 4 Oct 2023 22:18:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>
Message-ID: <MpkRFf-sK65cr6eE2DaHBaiMPANMG4b5h2i2iaeJdQA=.07d5389a-ce04-44c3-8bce-fd244b455140@github.com>

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed hotspot test

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15706#pullrequestreview-1658577826

From darcy at openjdk.org  Thu Oct  5 05:43:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 5 Oct 2023 05:43:36 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v4]
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <cFt00iQ5Ee8leQlbVx44urzuL8z4xJLuG5S3iTBzMWU=.5f35a708-2e93-47e6-a001-66aa908771ac@github.com>

> Change annotation processing to be opt-in rather than opt-out.

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

 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - Updates for a clean test run.
 - Merge branch 'master' into JDK-8306819
 - Merge branch 'master' into JDK-8306819
 - JDK-8306819: Consider disabling the compiler's default active annotation processing

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

Changes: https://git.openjdk.org/jdk/pull/14432/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=03
  Stats: 53 lines in 5 files changed: 17 ins; 8 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/14432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14432/head:pull/14432

PR: https://git.openjdk.org/jdk/pull/14432

From asotona at openjdk.org  Thu Oct  5 06:37:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Oct 2023 06:37:25 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v14]
In-Reply-To: <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <aSXvjyOfUWiIUEoz4dGtIdXbNqrXPTzFQuwbPwX3d4w=.b56a32ff-52ab-441a-86ff-f9487a3a8721@github.com>
Message-ID: <kNBiqRrDGT9eKz8lAQjM7chilSwCqg7_45QK1gX2vKY=.f2e57752-76c1-4dd7-8e89-6209cd7e36e9@github.com>

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed hotspot test

Thank you for all the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1748174064

From abimpoudis at openjdk.org  Thu Oct  5 08:20:58 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 08:20:58 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Declutter Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ef98c040..ceee1e4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=06-07

  Stats: 91 lines in 1 file changed: 22 ins; 43 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Thu Oct  5 08:21:04 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 08:21:04 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <zlcRgoJ6c2d_Q7Y1M9GGar-OVCrxcnaGe7gUb5JKLiU=.48589a40-d0fe-4655-b0b7-89e52401621d@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <zlcRgoJ6c2d_Q7Y1M9GGar-OVCrxcnaGe7gUb5JKLiU=.48589a40-d0fe-4655-b0b7-89e52401621d@github.com>
Message-ID: <udkcqmDBdw7Kvtzn0JYadJwDP3vdh3VEeUCcQz6-lhU=.815c56a3-d1c7-4d98-954b-c577f81c873f@github.com>

On Tue, 3 Oct 2023 08:54:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into primitive-patterns
>>  - Implement type pairs to exactnessMethod name
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
>>  - 8303374: Compiler Implementation for Primitive types in patterns, instanceof, and switch (Preview)
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2929:
> 
>> 2927:             // This branch covers true unconditionality for the underlying type as well.
>> 2928:             if (types.checkUnconditionallyExact(tree.expr.type, tree.pattern.type) &&
>> 2929:                 !(tree.expr.type.isReference() && types.isExactPrimitiveWidening(types.unboxedType(tree.expr.type), tree.pattern.type))) {
> 
> Not super sure I get this line: if the expression type is unconditionally exact for the pattern type, shouldn't the test be always `true` ? What is the role of the extra guard after the `&&` ? Also, doesn't unconditionally exact implies that there is convertibility?

Agree to all. Convertibility was covered.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1346991986

From abimpoudis at openjdk.org  Thu Oct  5 08:21:07 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 08:21:07 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <HavdMPItNJNFegZnxo_oq95yrBJ4jYljtfE3IkNQzMk=.e4389ce7-0909-488b-b498-6ec2cb29e919@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <fcne-uFcuwFi8D3_C6SZ6Vm2QRv1LVdtY52f626Ie7w=.0c4be90d-5519-4111-9302-9ac0acbe0427@github.com>
 <HavdMPItNJNFegZnxo_oq95yrBJ4jYljtfE3IkNQzMk=.e4389ce7-0909-488b-b498-6ec2cb29e919@github.com>
Message-ID: <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>

On Tue, 3 Oct 2023 09:05:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2982:
>> 
>>> 2980:                     // =>
>>> 2981:                     // if (let tmp$123 = v; ExactnessChecks.int_float(tmp$123))
>>> 2982:                     JCIdent argument = make.Ident(dollar_s);
>> 
>> In principle you don't need a synthetic variable here... (but it's ok if you prefer to leave for uniformity)
>
> Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.
> 
> I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).
> 
> Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.
> 
> In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.
> 
> While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?

Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1346993616

From mcimadamore at openjdk.org  Thu Oct  5 10:02:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Oct 2023 10:02:37 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
Message-ID: <Cm9cILUqR6B3lvN9wednezAMcEisceau0ztoZSoiXyQ=.1ce5b133-eef5-48a6-9702-5a9a1163e659@github.com>

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declutter Lower.visitTypeTest

src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 35:

> 33:  * @since 22
> 34:  */
> 35: final public class ExactnessMethods {

I think it should be `public final` (order of modifier)

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 558:

> 556:     }
> 557: 
> 558:     record TypePairs(Class<?> from, Class<?> to) {

Nice!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347148799
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347149579

From mcimadamore at openjdk.org  Thu Oct  5 10:10:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Oct 2023 10:10:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
Message-ID: <jaFsVoBScAZ7LvqhzdnYzioeBetqAZWN4vquut2WT0w=.af86577d-d4f2-4928-b589-8235b1a85548@github.com>

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declutter Lower.visitTypeTest

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2938:

> 2936:                 }
> 2937:             }
> 2938:             else if (tree.expr.type.isReference()) {

Much better logic!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347162809

From mcimadamore at openjdk.org  Thu Oct  5 10:15:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Oct 2023 10:15:23 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
Message-ID: <lIur7FDZZLlUXMkTaJ9hVfHkUoV-8WCuln_SEgMCV9I=.1a1ca483-f375-4087-8ce2-8b50e19e026c@github.com>

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Declutter Lower.visitTypeTest

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 230:

> 228:                          if (selectorType.equals(Object.class)) {
> 229:                             currentTest = INSTANCEOF_CHECK;
> 230:                             if (currentLabelClass.isAssignableFrom(byte.class)) { testLabel = Byte.class; }

I assume here you want to box the primitive, right? If that's the case, consider using the JDK class `sun.invoke.util.Wrapper`, which has a factory `forBasicType` that takes a class. From there you can get the boxed type easily, in a single line.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347171504

From abimpoudis at openjdk.org  Thu Oct  5 11:03:47 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 11:03:47 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v9]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <g_A-6RblH62KgqxRNIzQvEID9HQZpu9_a6rD880Bjmc=.555888dd-1a82-43b4-8cbe-6166ddc965ec@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Use sun.invoke.util.Wrapper in SwitchBootstraps

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ceee1e4c..c8b860d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=07-08

  Stats: 10 lines in 3 files changed: 1 ins; 6 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Thu Oct  5 11:23:15 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 11:23:15 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v8]
In-Reply-To: <Cm9cILUqR6B3lvN9wednezAMcEisceau0ztoZSoiXyQ=.1ce5b133-eef5-48a6-9702-5a9a1163e659@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <rbgm4yVDS-fJoGL16vXXGJx5KDqsddIR2ZWiDq7HT9w=.a7cdc606-60c1-49f0-9157-94dc1a74f37b@github.com>
 <Cm9cILUqR6B3lvN9wednezAMcEisceau0ztoZSoiXyQ=.1ce5b133-eef5-48a6-9702-5a9a1163e659@github.com>
Message-ID: <3_dYhTYH2wTojdNSbjB9VWmH6SZtO-fC9IFXAVQD3v4=.72a9449c-1be4-4ffa-9b9a-132219d52b24@github.com>

On Thu, 5 Oct 2023 09:58:52 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Declutter Lower.visitTypeTest
>
> src/java.base/share/classes/java/lang/runtime/ExactnessMethods.java line 35:
> 
>> 33:  * @since 22
>> 34:  */
>> 35: final public class ExactnessMethods {
> 
> I think it should be `public final` (order of modifier)

Done

> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 230:
> 
>> 228:                          if (selectorType.equals(Object.class)) {
>> 229:                             currentTest = INSTANCEOF_CHECK;
>> 230:                             if (currentLabelClass.isAssignableFrom(byte.class)) { testLabel = Byte.class; }
> 
> I assume here you want to box the primitive, right? If that's the case, consider using the JDK class `sun.invoke.util.Wrapper`, which has a factory `forBasicType` that takes a class. From there you can get the boxed type easily, in a single line.

Perfect! Exactly what I needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347256678
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347256224

From equintanilla at bnext.mx  Tue Oct  3 23:35:19 2023
From: equintanilla at bnext.mx (Eduardo Quintanilla)
Date: Tue, 3 Oct 2023 23:35:19 +0000
Subject: New candidate JEP: 458: Launch Multi-File Source-Code Programs
In-Reply-To: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>
References: <20231003152546.C4D92649DC2@eggemoggin.niobe.net>
Message-ID: <SN4PR19MB53443EC74867773235DAFEBEB1C4A@SN4PR19MB5344.namprd19.prod.outlook.com>

What can we expect in terms of performance? Faster than the separate compilation step for multi-file programs?.


-----Original Message-----
From: jdk-dev <jdk-dev-retn at openjdk.org> On Behalf Of Mark Reinhold
Sent: martes, 3 de octubre de 2023 09:26 a. m.
To: Ron Pressler <ron.pressler at oracle.com>
Cc: compiler-dev at openjdk.org; jdk-dev at openjdk.org
Subject: New candidate JEP: 458: Launch Multi-File Source-Code Programs


REMITENTE EXTERNO
PRECAUCI?N CON EL CONTENIDO DEL CORREO, NO ABRA ARCHIVOS NO SOLICITADOS Y NO ENV?E INFORMACI?N SIN VALIDAR EL RECEPTOR.


https://openjdk.org/jeps/458

  Summary: Enhance the java application launcher to be able to run a
  program supplied as multiple files of Java source code. This will
  make the transition from small programs to larger ones more gradual,
  enabling developers to choose whether and when to go to the trouble of
  configuring a build tool.

- Mark


The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
La informaci?n transmitida est? destinada ?nicamente a la persona o entidad a quien que va dirigida y puede contener informaci?n confidencial y/o material privilegiado. Cualquier revisi?n, retransmisi?n, difusi?n u otros usos, o cualquier acci?n tomada por personas o entidades distintas al destinatario bas?ndose en esta informaci?n est? prohibida. Si usted recibe este mensaje por error, por favor contacte al remitente y elimine el material de cualquier computadora.

From abimpoudis at openjdk.org  Thu Oct  5 15:13:57 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 15:13:57 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v10]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <qsQGFJD4If_BHDw3JLdcV_lt3IfYx0Ahn9hHBsBCGbU=.10acc664-e62b-4e7f-a30b-dc5930b4529a@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix `checkUnconditionallyExact` and adjust the type of numeric constants (to primitive type)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/c8b860d6..c041d208

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=08-09

  Stats: 11 lines in 2 files changed: 3 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Thu Oct  5 15:14:13 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 15:14:13 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <fcne-uFcuwFi8D3_C6SZ6Vm2QRv1LVdtY52f626Ie7w=.0c4be90d-5519-4111-9302-9ac0acbe0427@github.com>
 <HavdMPItNJNFegZnxo_oq95yrBJ4jYljtfE3IkNQzMk=.e4389ce7-0909-488b-b498-6ec2cb29e919@github.com>
 <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
Message-ID: <C186AShVuKt--lhQLx3Y5eNXY9gFVyRRnu8Jm4fvDeA=.a2418818-4f9b-43e9-a282-30974c572e1c@github.com>

On Thu, 5 Oct 2023 08:14:53 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Aren't there cases here where the type of the expr is unconditional w.r.t. the type of the pattern (and so, no test is required) ? Perhaps the case I'm thinking of is dealt with one of the ifs at the beginning of this method.
>> 
>> I have to say I'm a bit confused by how this method is arranged. From a logical perspective I would expect first and foremost to test if the pattern type is a primitive, because that's the only case where Lower needs to do anything (right?).
>> 
>> Then you can have two cases: the expression has a reference type, in which case you need null check and unboxing. Or the expression has a primitive type.
>> 
>> In both cases you can be in a situation where the conversion is provably exact, so no need to call the exactness routine - or you can be in an inexact situation where a runtime test is required.
>> 
>> While I'm sure that is what happens in the above code, I think perhaps the various tests could be arranged in a way to make the above structure pop out a little more?
>
> Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.

`checkUnconditionallyExact` and dominance for constants were adjusted accordingly in https://github.com/openjdk/jdk/pull/15638/commits/c041d208a6fc6beaf785e8a400815fb4a7d08e78 ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1347473254

From abimpoudis at openjdk.org  Thu Oct  5 15:24:40 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 5 Oct 2023 15:24:40 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v11]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <YZYyeOpH0sBODTkkAARacgqDHNTr9xvOfD1a22Jw3NI=.ac861af6-b7a6-4c08-9b90-6f65ad866a36@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Fix `checkUnconditionallyExact` and adjust the type of numeric constants (to primitive type)
 - Use sun.invoke.util.Wrapper in SwitchBootstraps
 - Declutter Lower.visitTypeTest
 - Simplify TypePairs
 - Rename exactness methods
 - Remove unnecessary disambiguation in TransPatterns and simplify Lower.visitTypeTest
 - Fix exhausts and equals in SwitchBootstraps
 - Merge branch 'master' into primitive-patterns
 - Implement type pairs to exactnessMethod name
 - ... and 2 more: https://git.openjdk.org/jdk/compare/228a2389...ff07aef9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/c041d208..ff07aef9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=09-10

  Stats: 7735 lines in 265 files changed: 3202 ins; 1731 del; 2802 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From asotona at openjdk.org  Thu Oct  5 15:25:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 5 Oct 2023 15:25:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v15]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <C42Y_j3Fw2uxso5gIFscoCgIUEpJJAaA0fKcjWf8cyo=.812abea6-21a2-47df-bee3-9eee11718be9@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with five additional commits since the last revision:

 - improved ClassFile constants javadoc
 - fixed AnnotationValue::of javadoc
 - fixed elements javadoc
 - Typo in BufWriter javadoc
 - cleanup in CustomAttribute

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/a6a73b37..7fe5db2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=13-14

  Stats: 401 lines in 13 files changed: 40 ins; 11 del; 350 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From xqoasis at openjdk.org  Fri Oct  6 01:03:00 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Fri, 6 Oct 2023 01:03:00 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <UxDg7rBpOoShWQXXlk6jo2SQRuhVJk6pyG4mr5j-YgM=.0d55c8b4-ec3e-4358-9e7e-b8a90c05a3c4@github.com>

On Mon, 14 Aug 2023 23:57:08 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

@sormuras Hi Christian. Can I ask whether you find any reviewer for this PR? Otherwise, it will be closed after 4 weeks. I can make any modifications if needed. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/15281#issuecomment-1749849178

From abimpoudis at openjdk.org  Fri Oct  6 11:23:47 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 6 Oct 2023 11:23:47 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v12]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <EEzkNT92vx_o8he4n_lLlVA3NUjsLY7BXnPSNORDYTA=.9f81c11c-34ab-4189-a838-d525fbff87d8@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix Lower.visitTypeTest

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ff07aef9..01ebecd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=10-11

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

PR: https://git.openjdk.org/jdk/pull/15638

From mcimadamore at openjdk.org  Fri Oct  6 11:40:54 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Oct 2023 11:40:54 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <C186AShVuKt--lhQLx3Y5eNXY9gFVyRRnu8Jm4fvDeA=.a2418818-4f9b-43e9-a282-30974c572e1c@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <fcne-uFcuwFi8D3_C6SZ6Vm2QRv1LVdtY52f626Ie7w=.0c4be90d-5519-4111-9302-9ac0acbe0427@github.com>
 <HavdMPItNJNFegZnxo_oq95yrBJ4jYljtfE3IkNQzMk=.e4389ce7-0909-488b-b498-6ec2cb29e919@github.com>
 <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
 <C186AShVuKt--lhQLx3Y5eNXY9gFVyRRnu8Jm4fvDeA=.a2418818-4f9b-43e9-a282-30974c572e1c@github.com>
Message-ID: <1HWKJZ2MQ3GUFLV2syrWzOMTEsSGH_JNYjplw7Tql_Y=.60d43713-3eac-4042-a8ad-ab9347ea3589@github.com>

On Thu, 5 Oct 2023 14:00:12 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> Refactoring attempt No. 1 complete. I need to recheck the completeness of `checkUnconditionallyExact`. In a following commit.
>
> `checkUnconditionallyExact` and dominance for constants were adjusted accordingly in https://github.com/openjdk/jdk/pull/15638/commits/c041d208a6fc6beaf785e8a400815fb4a7d08e78 ?

The new logic is much better and simpler to follow - thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1348608306

From mcimadamore at openjdk.org  Fri Oct  6 11:40:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 6 Oct 2023 11:40:56 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v3]
In-Reply-To: <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 <n7BRe-KOvAqgszEVLd-SwQ-oIabSlnDhAez9BzYRocw=.6002fac7-6b80-4fca-a198-bd843c23e58c@github.com>
 <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>
Message-ID: <aG4HieayiOxo1W3YSyodW-6a3B89bCWMORQNk4NHNIA=.1d0c8e26-3fdc-4d25-99a4-64cde9ea0d50@github.com>

On Wed, 4 Oct 2023 10:08:31 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 3001:
>> 
>>> 2999:     }
>>> 3000: 
>>> 3001:     static class TypePairs {
>> 
>> I believe this could be a record between two TypeSymbols? Then you could have an additional constructor that takes two types and retrieves their `tsym` and call the canonical constructor (and then you can drop equals/hashcode).
>
> Done and simplified https://github.com/openjdk/jdk/pull/15638/commits/ef98c040c909981077936c6ff4280b6da04b8c24. Do you think we can simplify further (or benefit at all) by also eliminating duplication between SwitchBootstrap and Lower?

I don't think there's an easy easy way to deduplicate the code, as the code occurs in two different modules, so it's messy (as bootstrap javac compilation cannot depend on stuff that is in the latest latest JDK, as it has to compile against JDK N-1, and, on the other hand, java.base cannot depend on any other modules). So, leave it as is, maybe add a comment that the code should stay in sync :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1348607516

From abimpoudis at openjdk.org  Fri Oct  6 11:58:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 6 Oct 2023 11:58:38 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v13]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <kDT5CjVQyyx98prKGFk70xntphw0eBTmnOr4QsC6oho=.3ae56f6e-2491-4c39-9a8c-bee1627fc956@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add comment for TypePairs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/01ebecd9..f1a5e141

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=11-12

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

PR: https://git.openjdk.org/jdk/pull/15638

From duke at openjdk.org  Fri Oct  6 15:04:10 2023
From: duke at openjdk.org (duke)
Date: Fri, 6 Oct 2023 15:04:10 GMT
Subject: Withdrawn: 8305955: Remove Visual C++ specific workaround in javac
In-Reply-To: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
References: <TUqfwcm0nTZz1m1MjV0kVAOXwmO735By8LIxvGsNMoI=.9d24bb01-0b52-43e2-8d0b-d5cc925b3056@github.com>
Message-ID: <GuA1tf-3Y8t8hRWVC1BxG3l05d9lThoV2nMv80RGfEA=.0efa7505-2c7d-4916-ad05-6163694eeba5@github.com>

On Thu, 13 Apr 2023 11:36:15 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Visual C++ no longer requires the use of the i64 literal syntax and instead recommends the use of LL instead, so we should remove this workaround in the JNIWriter (this also helps when users write Windows JNI code meant to be compiled with alternate compilers other than Visual C++)

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.org/jdk/pull/13457

From darcy at openjdk.org  Fri Oct  6 20:40:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 6 Oct 2023 20:40:53 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v5]
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <AsfmbaplTAl1gmOdP7f967ss7PnPZwhCeDDfK7I77jQ=.cf87ab5e-3df3-4407-b874-c16a79cdb535@github.com>

> Change annotation processing to be opt-in rather than opt-out.

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

  Implement review feedback.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14432/files
  - new: https://git.openjdk.org/jdk/pull/14432/files/805791cf..b90d18c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/14432

From archie.cobbs at gmail.com  Fri Oct  6 21:08:01 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 6 Oct 2023 16:08:01 -0500
Subject: -Xlint:unnecessary ?
Message-ID: <CANSoFxvjBXx1ZVnupbfWjmDrhRncHx0yUZqgKq1rZ_mtTqXc4w@mail.gmail.com>

I had an idea for a new lint warning and wanted to get feedback from those
who understand the lint system better than me about the idea and whether
this is feasible.

The name of the new warning would be something like "unnecessary".

The idea is that if you said -Xlint:foobar,unnecessary then you would get a
warning for any unnecessary @SuppressWarnings("foobar") annotations,
meaning, there are actually no warnings that need suppressing at that spot,
and so the annotation is unnecessary and can be removed.

The reason you would need to do -Xlint:foobar,unnecessary instead of just
plain -Xlint:unnecessary to cover all of them is because in some cases if
-Xlint:foobar is not specified then the logic for detecting foobar warnings
is completely disabled, so it's not possible to know when the warning would
or would not have fired. Also, this makes the control more precise.

The benefit of this of course is it helps avoid accidental warning
suppression (false negatives) by making it easier to minimize your
suppression surface.

I started trying to evaluate doing this, but am not completely
understanding how lint and "deferred lint" interact.

Is there a lint expert who can comment on whether this would be feasible
given the way lint is currently implemented?

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231006/ad67ce3c/attachment-0001.htm>

From darcy at openjdk.org  Fri Oct  6 21:12:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 6 Oct 2023 21:12:05 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v6]
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <TL16SheAK22xOuUpD2o8D6eqmiMc3arZBArA0M7BmdM=.537e8c04-8645-4da8-83b2-ad2bfc755f95@github.com>

> Change annotation processing to be opt-in rather than opt-out.

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

  Update comments in test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14432/files
  - new: https://git.openjdk.org/jdk/pull/14432/files/b90d18c4..667411dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=04-05

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14432.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14432/head:pull/14432

PR: https://git.openjdk.org/jdk/pull/14432

From darcy at openjdk.org  Fri Oct  6 21:55:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 6 Oct 2023 21:55:30 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>

> Change annotation processing to be opt-in rather than opt-out.

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

  Fix typos.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14432/files
  - new: https://git.openjdk.org/jdk/pull/14432/files/667411dd..795e702f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14432&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/14432

From darcy at openjdk.org  Fri Oct  6 21:55:31 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 6 Oct 2023 21:55:31 GMT
Subject: Integrated: JDK-8306819: Consider disabling the compiler's default
 active annotation processing
In-Reply-To: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
Message-ID: <qsIh3tFWV-ibybG1_SYXQS-ByVZDyR3CqrZvHJRkWA8=.74cb39fe-0510-4f17-885a-8ffb4bbc474b@github.com>

On Mon, 12 Jun 2023 23:49:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Change annotation processing to be opt-in rather than opt-out.

This pull request has now been integrated.

Changeset: dc4bc4f0
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc4bc4f0844b768e83406f44f2a9ee50686b1d9d
Stats:     61 lines in 5 files changed: 23 ins; 15 del; 23 mod

8306819: Consider disabling the compiler's default active annotation processing

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/14432

From jjg at openjdk.org  Fri Oct  6 23:51:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 6 Oct 2023 23:51:17 GMT
Subject: RFR: JDK-8317693: Unused parameter to Tokens.Token.comment method
Message-ID: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>

Please review a simple cleanup to eliminate an unused parameter and rename the enclosing method.

No new tests; bug is primarily `noreg-cleanup`. Two tests were affected by the change, but are not in themselves tests for the change.

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

Commit messages:
 - JDK-8317693: Unused parameter to Tokens.Token.comment method

Changes: https://git.openjdk.org/jdk/pull/16088/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317693
  Stats: 26 lines in 5 files changed: 0 ins; 2 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/16088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16088/head:pull/16088

PR: https://git.openjdk.org/jdk/pull/16088

From iris at openjdk.org  Sat Oct  7 05:01:40 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 7 Oct 2023 05:01:40 GMT
Subject: RFR: JDK-8317693: Unused parameter to Tokens.Token.comment method
In-Reply-To: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>
References: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>
Message-ID: <E4Uz0euGjZZ9BGzfefzMlNU2IvPcJD96TvflkpVE5SY=.ce05cbb3-41fe-4272-91a4-5d2b27b99850@github.com>

On Fri, 6 Oct 2023 23:39:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple cleanup to eliminate an unused parameter and rename the enclosing method.
> 
> No new tests; bug is primarily `noreg-cleanup`. Two tests were affected by the change, but are not in themselves tests for the change.

Nice clean-up.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16088#pullrequestreview-1662997746

From attila.kelemen85 at gmail.com  Sat Oct  7 13:11:50 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Sat, 7 Oct 2023 15:11:50 +0200
Subject: -Xlint:unnecessary ?
In-Reply-To: <CANSoFxvjBXx1ZVnupbfWjmDrhRncHx0yUZqgKq1rZ_mtTqXc4w@mail.gmail.com>
References: <CANSoFxvjBXx1ZVnupbfWjmDrhRncHx0yUZqgKq1rZ_mtTqXc4w@mail.gmail.com>
Message-ID: <CAKDaPBc=O0oZGwSy_odiV3juSRUn6s66gLHnpZ+Cne84TieFMQ@mail.gmail.com>

I'm not an expert on lint by any means, but your proposed syntax is not
obvious to me, since we can already comma separate warnings to enable and
disable them separately. So, with the current syntax,
"-Xlint:foobar,unnecessary" would read as: Enable "foobar" warnings, Enable
"unnecessary" warnings. Maybe you meant to say that the definition of
"unnecessary" flag would be: Print warnings for unnecessary usage of
enabled warnings? That is not exactly "precise" though, because in that
case I can't say that "Don't report warnings for foobar, but report
unnecessary usage of it" (not that this would be terribly useful).

Only slightly related, but what I would like to see with -Xlint is a
selective "-Werror". That is, fail only on specific warnings, which I would
set to fail on every warning, but "deprecated" (because "deprecated"
warnings normally appear without you introducing the issue). In fact, my
specific pain is that I can't set error prone (or whatever else) to fail on
"rawtype", because they are saying it is the responsibility of javac, but
then I can't make javac fail on it unless I turn off "deprecated" warnings
(which I don't want to turn off).

Archie Cobbs <archie.cobbs at gmail.com> ezt ?rta (id?pont: 2023. okt. 7.,
Szo, 0:41):

> I had an idea for a new lint warning and wanted to get feedback from those
> who understand the lint system better than me about the idea and whether
> this is feasible.
>
> The name of the new warning would be something like "unnecessary".
>
> The idea is that if you said -Xlint:foobar,unnecessary then you would get
> a warning for any unnecessary @SuppressWarnings("foobar") annotations,
> meaning, there are actually no warnings that need suppressing at that spot,
> and so the annotation is unnecessary and can be removed.
>
> The reason you would need to do -Xlint:foobar,unnecessary instead of just
> plain -Xlint:unnecessary to cover all of them is because in some cases if
> -Xlint:foobar is not specified then the logic for detecting foobar
> warnings is completely disabled, so it's not possible to know when the
> warning would or would not have fired. Also, this makes the control more
> precise.
>
> The benefit of this of course is it helps avoid accidental warning
> suppression (false negatives) by making it easier to minimize your
> suppression surface.
>
> I started trying to evaluate doing this, but am not completely
> understanding how lint and "deferred lint" interact.
>
> Is there a lint expert who can comment on whether this would be feasible
> given the way lint is currently implemented?
>
> Thanks,
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231007/546de5c6/attachment.htm>

From darcy at openjdk.org  Sat Oct  7 16:32:10 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 7 Oct 2023 16:32:10 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body [v2]
In-Reply-To: <uBeD2wWRoLUMmEyTRv1NKDO0tefsgic9bOJo0NdKZbE=.347af0cf-1538-4ea8-af3b-298ffa816731@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
 <uBeD2wWRoLUMmEyTRv1NKDO0tefsgic9bOJo0NdKZbE=.347af0cf-1538-4ea8-af3b-298ffa816731@github.com>
Message-ID: <Nz0OhD23-yvDI1EI0tyI7BIUmJhUU6VTKE5nNqQsijo=.c5b9813f-0b1c-40f0-8a59-7e7ce5d827c5@github.com>

On Fri, 29 Sep 2023 18:53:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
>> 
>> 
>> enum T {
>>   ONE("");
>> 
>>   T(String one);  // missing constructor body
>> 
>>   final String one;
>> }
>> 
>> the fix is a one liner
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   addressing review comments

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15974#pullrequestreview-1663074693

From duke at openjdk.org  Sun Oct  8 05:53:17 2023
From: duke at openjdk.org (Danny Thomas)
Date: Sun, 8 Oct 2023 05:53:17 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
Message-ID: <BLNhDFMfiSgtCj6kYK9M-26nHUjLuGYokJk4MFH_Lb8=.9b8460fb-3294-4043-9cdf-951c98da2410@github.com>

On Fri, 6 Oct 2023 21:55:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos.

After much head scratching attempting to run the benchmarks for 8309130, I realised this change broke microbenchmarks:

$ make test TEST="micro:java.lang.ArraysSort"
Building target 'test' in configuration 'linux-x86_64-server-release'
...
Test selection 'micro:java.lang.ArraysSort', will run:
* micro:java.lang.ArraysSort

Running test 'micro:java.lang.ArraysSort'
Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find the resource: /META-INF/BenchmarkList
	at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98)
	at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124)
	at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252)
	at org.openjdk.jmh.runner.Runner.run(Runner.java:208)
	at org.openjdk.jmh.Main.main(Main.java:71)
Finished running test 'micro:java.lang.ArraysSort'
Test report is stored in build/linux-x86_64-server-release/test-results/micro_java_lang_ArraysSort

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1751929321

From forax at openjdk.org  Sun Oct  8 07:02:15 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sun, 8 Oct 2023 07:02:15 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
Message-ID: <k_PMvG6-v5EledEx37wIaPU35jXAMap9a4ObkOsC5zQ=.b6376077-c58e-47ec-a1ab-82a7f4f36e55@github.com>

On Fri, 6 Oct 2023 21:55:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos.

Yes, JMH is using an annotation processor which now does not run anymore

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1751941702

From duke at openjdk.org  Sun Oct  8 19:44:17 2023
From: duke at openjdk.org (Rob Bygrave)
Date: Sun, 8 Oct 2023 19:44:17 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <L9f6RG36zl89Hagzn-Nba6sdIOh168DW3IehpbpUBy0=.3e73cb95-ebc1-48cb-993b-f230cf6b9dfa@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
 <L9f6RG36zl89Hagzn-Nba6sdIOh168DW3IehpbpUBy0=.3e73cb95-ebc1-48cb-993b-f230cf6b9dfa@github.com>
Message-ID: <J5FV_g0pT-VKq8I5-9Jg0Q1G5u5LHTtmA9zX-HUN64o=.55324e37-9f2a-4e49-8e5b-7e150cae1510@github.com>

On Sun, 10 Sep 2023 15:33:15 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch isn't aimed to remove AP. This aims to avoid unintentional AP pollutions in classpath

Yes, I understand that.

> Such classpath separation have already been promoted by build tools like Gradle.

**_BUT_** it has **_NOT_** been promoted by **_Maven_**. In the bug report and in this PR I do not see any explicit recognition of how this change will impact the community that is using Maven and I am suggesting that this is a significant proportion of the community.

For example, all the libraries that use annotation processing that document maven use could be impacted along the lines that their documentation will now be at least misleading (and sometimes incorrect). 

This change might indeed be a good long term change but it seems to be being made without any recognition or understanding of how impactful it will be.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1712962790

From jlahoda at openjdk.org  Mon Oct  9 08:16:11 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 9 Oct 2023 08:16:11 GMT
Subject: RFR: JDK-8317693: Unused parameter to Tokens.Token.comment method
In-Reply-To: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>
References: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>
Message-ID: <plmeGRSk974SeUUpRk2qLKrnZ1Kuo5wCbd6-bov2m68=.4acd25a0-7519-4f09-9e12-d70b967efdcb@github.com>

On Fri, 6 Oct 2023 23:39:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple cleanup to eliminate an unused parameter and rename the enclosing method.
> 
> No new tests; bug is primarily `noreg-cleanup`. Two tests were affected by the change, but are not in themselves tests for the change.

Makes sense to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16088#pullrequestreview-1663925668

From asotona at openjdk.org  Mon Oct  9 14:09:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 9 Oct 2023 14:09:29 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v16]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <CnO67E2iRAg66ZHB4w3fB-k6VSkidsmskDnJx8v98Mc=.08acfe0f-49a2-4bb1-9c52-5cf81b45a2c1@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - removed AttributeMapper::validSince
 - fixed DirectCodeBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/7fe5db2b..21f4bb03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=14-15

  Stats: 105 lines in 25 files changed: 47 ins; 30 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Mon Oct  9 15:11:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 9 Oct 2023 15:11:23 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v17]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <XGJwSuIFVtDNjDEFrwcI2I-s6rxx0fckPS_ek-RZYiY=.e70e2c5b-e119-4473-ab03-fc22f87028b1@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/21f4bb03..ad6aadf1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=15-16

  Stats: 13 lines in 4 files changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From abimpoudis at openjdk.org  Mon Oct  9 16:53:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 9 Oct 2023 16:53:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v14]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <9dRLbVIVYt77YCrnbFnZY4b-bAh572yvBj5GhETNCVM=.d7e8c829-c3d7-452b-883f-5bdac26d5d72@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with five additional commits since the last revision:

 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - Fixing error conditions, tweaking tests.
 - Attempting to improve reported errors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/f1a5e141..cdaa186c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=12-13

  Stats: 496 lines in 13 files changed: 351 ins; 84 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From jjg at openjdk.org  Mon Oct  9 17:57:09 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 9 Oct 2023 17:57:09 GMT
Subject: Integrated: JDK-8317693: Unused parameter to Tokens.Token.comment
 method
In-Reply-To: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>
References: <OVOJU8EDnQZr-DVRZqSZGtDnUkI9oxUGclzZvpBAOjM=.d1eebcda-8e03-4bef-98cd-6a4965905473@github.com>
Message-ID: <iRbtHfaFa_HDZoNcAQoWOyT3m34tcBidgkRkXROKVT4=.3123a341-9655-433d-b709-39c9777fb119@github.com>

On Fri, 6 Oct 2023 23:39:27 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple cleanup to eliminate an unused parameter and rename the enclosing method.
> 
> No new tests; bug is primarily `noreg-cleanup`. Two tests were affected by the change, but are not in themselves tests for the change.

This pull request has now been integrated.

Changeset: 3ff5a781
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ff5a781db1c9b5105b1890fe495c17dc382af5d
Stats:     26 lines in 5 files changed: 0 ins; 2 del; 24 mod

8317693: Unused parameter to Tokens.Token.comment method

Reviewed-by: iris, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/16088

From abimpoudis at openjdk.org  Mon Oct  9 21:08:42 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 9 Oct 2023 21:08:42 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v15]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <sTLQeyuS388lp3IEeLHeBd1umJlx1Lh6_JeawCYOw0I=.7a294255-750f-41e5-accf-6c07e399745b@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/instanceof-20230913/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Adjust tests
  
  Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
  Co-authored-by: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/cdaa186c..bab26337

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=13-14

  Stats: 96 lines in 9 files changed: 34 ins; 56 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From cushon at google.com  Mon Oct  9 21:45:51 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Mon, 9 Oct 2023 14:45:51 -0700
Subject: condy and enums
Message-ID: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>

Hello,

I'd like to discuss the idea of using constant dynamic in the generated
code for enums.

The possibility of using condy came up in the review thread for
JDK-8241798, which implemented a small change to the code generation
strategy for enums to raise the limit on the number of enum constants. To
recap, there are limits on the number of constants in an enum imposed by
the class file format. The constants are represented as static final
fields, which have to be initialized in the clinit, which eventually runs
into the 64k method size limit:

https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html
https://bugs.openjdk.org/browse/JDK-8241798

I did some recent experimentation into using condy to initialize enum
constants and create the values array. There's a very rough draft here:
https://github.com/openjdk/jdk/pull/16108

With that change the clinit just contains a ldc/putstatus for each
constant, which is 6 bytes per constant, raising the limit on the number of
constants from ~4k today to about 10k.

I am interested in high level feedback about the idea. Does this seem like
a good use of condy, or a bad use of condy? Are there reasons (performance,
maintenance, other things I'm not considering) why using condy in this way
wouldn't be advisable?

One caveat is that it may not be very valuable to raise the limit further.
Four thousand is already a lot of enum constants. I suspect for many
domains where it's necessary to represent >4k values, it will eventually
need to represent >10k values, and that enums are not the best way to model
those domains. So I wouldn't argue for doing this if there end up being a
lot of trade-offs, but if the condy approach was appealing in general
perhaps raising the limit at the same time could be win-win.

Working through the prototype raised some questions about what a production
quality implementation would look like:

Enums with user-defined constructors are currently only handled if the
arguments are static constants. What would the right solution be? Perhaps a
factory method could be synthetized for constants with non-constant
arguments, so condy could still be used to load them.

The class initializer for MethodHandle transitively loads enums, so having
enum class initializers use condy creates a cyclic dependency. The
prototype skips the new strategy for java.base. I could imagine having a
way to opt specific enums out of the new strategy, but having to maintain
multiple code generation strategies for enums does not seem very appealing.
Perhaps there's a way to refactor to break those cycles, or that the lazy
static final field proposal in JDK-8209964 could help here, or something
else.

I'm curious what you think,
Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231009/2dfd6650/attachment.htm>

From archie.cobbs at gmail.com  Mon Oct  9 21:58:52 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 9 Oct 2023 16:58:52 -0500
Subject: condy and enums
In-Reply-To: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
Message-ID: <CANSoFxuc95QDM0ya727BhkiFVfwqXKiUYvOKgMNvqqB0espvAQ@mail.gmail.com>

Hi Liam,

I don't have any strong opinions but would like to point out that this
change may also impact JDK-8219412
<https://bugs.openjdk.org/browse/JDK-8219412> (probably in a good way).

See also this relevant discussion:
https://mail.openjdk.org/pipermail/compiler-dev/2023-January/021662.html

-Archie

On Mon, Oct 9, 2023 at 4:46?PM Liam Miller-Cushon <cushon at google.com> wrote:

> Hello,
>
> I'd like to discuss the idea of using constant dynamic in the generated
> code for enums.
>
> The possibility of using condy came up in the review thread for
> JDK-8241798, which implemented a small change to the code generation
> strategy for enums to raise the limit on the number of enum constants. To
> recap, there are limits on the number of constants in an enum imposed by
> the class file format. The constants are represented as static final
> fields, which have to be initialized in the clinit, which eventually runs
> into the 64k method size limit:
>
> https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html
> https://bugs.openjdk.org/browse/JDK-8241798
>
> I did some recent experimentation into using condy to initialize enum
> constants and create the values array. There's a very rough draft here:
> https://github.com/openjdk/jdk/pull/16108
>
> With that change the clinit just contains a ldc/putstatus for each
> constant, which is 6 bytes per constant, raising the limit on the number of
> constants from ~4k today to about 10k.
>
> I am interested in high level feedback about the idea. Does this seem like
> a good use of condy, or a bad use of condy? Are there reasons (performance,
> maintenance, other things I'm not considering) why using condy in this way
> wouldn't be advisable?
>
> One caveat is that it may not be very valuable to raise the limit further.
> Four thousand is already a lot of enum constants. I suspect for many
> domains where it's necessary to represent >4k values, it will eventually
> need to represent >10k values, and that enums are not the best way to model
> those domains. So I wouldn't argue for doing this if there end up being a
> lot of trade-offs, but if the condy approach was appealing in general
> perhaps raising the limit at the same time could be win-win.
>
> Working through the prototype raised some questions about what a
> production quality implementation would look like:
>
> Enums with user-defined constructors are currently only handled if the
> arguments are static constants. What would the right solution be? Perhaps a
> factory method could be synthetized for constants with non-constant
> arguments, so condy could still be used to load them.
>
> The class initializer for MethodHandle transitively loads enums, so having
> enum class initializers use condy creates a cyclic dependency. The
> prototype skips the new strategy for java.base. I could imagine having a
> way to opt specific enums out of the new strategy, but having to maintain
> multiple code generation strategies for enums does not seem very appealing.
> Perhaps there's a way to refactor to break those cycles, or that the lazy
> static final field proposal in JDK-8209964 could help here, or something
> else.
>
> I'm curious what you think,
> Liam
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231009/f7de4c06/attachment.htm>

From cstein at openjdk.org  Tue Oct 10 04:50:56 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Oct 2023 04:50:56 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <GP259Vgl83QYqb1eadNrjtnSrIX2_j8234XOHpIw6i4=.f863dc43-eadb-468d-8ad1-78deac7f26bc@github.com>

On Mon, 14 Aug 2023 23:57:08 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

test/langtools/lib/combo/tools/javac/combo/JavacTemplateDiagnosticsPrinter.java line 38:

> 36:  * Class for TestWatcher implementation.
> 37:  */
> 38: public class JavacTemplateDiagnosticPrinter extends JavacTemplateTestBase {

This newly introduced class `JavacTemplateDiagnostic[s]Printer` (including a mismatch in filename and class name) is not used anywhere. Delete it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15281#discussion_r1351439653

From xqoasis at openjdk.org  Tue Oct 10 04:57:57 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Tue, 10 Oct 2023 04:57:57 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests
In-Reply-To: <GP259Vgl83QYqb1eadNrjtnSrIX2_j8234XOHpIw6i4=.f863dc43-eadb-468d-8ad1-78deac7f26bc@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <GP259Vgl83QYqb1eadNrjtnSrIX2_j8234XOHpIw6i4=.f863dc43-eadb-468d-8ad1-78deac7f26bc@github.com>
Message-ID: <u4qLtJ2B1S5lW4CZPY1crino4ERKfeuBrH022kbjS5A=.c1857110-abd6-40f6-811b-5649a1f1a723@github.com>

On Tue, 10 Oct 2023 04:48:05 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
>> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.
>
> test/langtools/lib/combo/tools/javac/combo/JavacTemplateDiagnosticsPrinter.java line 38:
> 
>> 36:  * Class for TestWatcher implementation.
>> 37:  */
>> 38: public class JavacTemplateDiagnosticPrinter extends JavacTemplateTestBase {
> 
> This newly introduced class `JavacTemplateDiagnostic[s]Printer` (including a mismatch in filename and class name) is not used anywhere. Delete it?

I see. Sorry for this mistake. I should have deleted it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15281#discussion_r1351443463

From xqoasis at openjdk.org  Tue Oct 10 05:18:34 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Tue, 10 Oct 2023 05:18:34 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v2]
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <Cqz6p5sDVHx8qu7KvgfC9QMLxIK9RHCWpqti_E7Vfqg=.e889a288-4835-40c3-aa93-e17d8377973b@github.com>

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  remove unused JavacTemplateDiagnosticsPrinter.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15281/files
  - new: https://git.openjdk.org/jdk/pull/15281/files/81326627..5f9f0f60

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=00-01

  Stats: 58 lines in 1 file changed: 0 ins; 58 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15281/head:pull/15281

PR: https://git.openjdk.org/jdk/pull/15281

From abimpoudis at openjdk.org  Tue Oct 10 09:52:34 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 10 Oct 2023 09:52:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v16]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <02ST2uGvMQt4V_x1Yja4iRv9qStRTlPb30RjDRblhBQ=.9e469bd1-fb9d-4cd9-9db3-3bd81aa95837@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
   Co-authored-by: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - Fixing error conditions, tweaking tests.
 - Attempting to improve reported errors.
 - Add comment for TypePairs
 - Fix Lower.visitTypeTest
 - Merge branch 'master' into primitive-patterns
 - ... and 11 more: https://git.openjdk.org/jdk/compare/5ea9a0ea...3030dc14

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/bab26337..3030dc14

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=14-15

  Stats: 5174 lines in 100 files changed: 3529 ins; 943 del; 702 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From maurizio.cimadamore at oracle.com  Tue Oct 10 10:34:07 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 10 Oct 2023 11:34:07 +0100
Subject: condy and enums
In-Reply-To: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
Message-ID: <bc21a757-328c-4cf3-8687-3641b3da698c@oracle.com>

Hi Liam,
the overall idea seem fine. I'm a bit on the fence (as I think you 
already are) when I try to assess whether adding the extra complexity is 
worth it here. On the one hand, the code we have today is not very 
compact, but the javac translation strategy is quite uniform, and can 
deal with both enum construction and custom enums (e.g. enums which 
define their own bodies). The approach proposed here, while it's more 
compact for the case where an enum has no parameters (or where the 
parameters are not constant), it has to contain some fallback logic for 
the more general case, so the resulting lowering code becomes a little 
bit more cryptic to understand, and maintain (going forward).

Do you have some data re. how many enum construction can be optimized 
with this approach? Trying to think about code I've seen in the past, 
the assumption that enum construction parameters are constant doesn't 
strike me as too unrealistic, so I would expect that a lot of enums out 
there could be optimized by this path (in which case I'd be more willing 
to consider it).

Thanks for the great work!
Maurizio


On 09/10/2023 22:45, Liam Miller-Cushon wrote:
> Hello,
>
> I'd like to discuss the idea of using constant dynamic in the 
> generated code for enums.
>
> The possibility of using condy came up in the review thread for 
> JDK-8241798, which implemented a small change to the code generation 
> strategy for enums to raise the limit on the number of enum constants. 
> To recap, there are limits on the number of constants in an enum 
> imposed by the class file format. The constants are represented as 
> static final fields, which have to be initialized in the clinit, which 
> eventually runs into the 64k method size limit:
>
> https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html
> https://bugs.openjdk.org/browse/JDK-8241798
>
> I did some recent experimentation into using condy to initialize enum 
> constants and create the values array. There's a very rough draft 
> here: https://github.com/openjdk/jdk/pull/16108
>
> With that change the clinit just contains a ldc/putstatus for each 
> constant, which is 6 bytes per constant, raising the limit on the 
> number of constants from ~4k today to about 10k.
>
> I am interested in high level feedback about the idea. Does this seem 
> like a good use of condy, or a bad use of condy? Are there reasons 
> (performance, maintenance, other things I'm not considering) why using 
> condy in this way wouldn't be advisable?
>
> One caveat is that it may not be very valuable to raise the limit 
> further. Four thousand is already a lot of enum constants. I suspect 
> for many domains where it's necessary to represent >4k values, it will 
> eventually need to represent >10k values, and that enums are not the 
> best way to model those domains. So I wouldn't argue for doing this if 
> there end up being a lot of trade-offs, but if the condy approach was 
> appealing in general perhaps raising the limit at the same time could 
> be win-win.
>
> Working through the prototype raised some questions about what a 
> production quality implementation would look like:
>
> Enums with user-defined constructors are currently only handled if the 
> arguments are static constants. What would the right solution be? 
> Perhaps a factory method could be synthetized for constants with 
> non-constant arguments, so condy could still be used to load them.
>
> The class initializer for MethodHandle transitively loads enums, so 
> having enum class initializers use condy creates a cyclic dependency. 
> The prototype skips the new strategy for java.base. I could imagine 
> having a way to opt specific enums out of the new strategy, but having 
> to maintain multiple code generation strategies for enums does not 
> seem very appealing. Perhaps there's a way to refactor to break those 
> cycles, or that the lazy static final field proposal in JDK-8209964 
> could help here, or something else.
>
> I'm curious what you think,
> Liam

From asotona at openjdk.org  Tue Oct 10 11:29:40 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 10 Oct 2023 11:29:40 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v18]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 348 commits:

 - Merge branch 'master' into JDK-8308753-preview
 - added @sealedGraph tags
 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test
 - removed AttributeMapper::validSince
 - fixed DirectCodeBuilder
 - improved ClassFile constants javadoc
 - fixed AnnotationValue::of javadoc
 - fixed elements javadoc
 - Typo in BufWriter javadoc
 - ... and 338 more: https://git.openjdk.org/jdk/compare/ad7a8e86...5e537a86

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=17
  Stats: 32099 lines in 763 files changed: 14605 ins; 14018 del; 3476 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From cstein at openjdk.org  Tue Oct 10 13:32:43 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 10 Oct 2023 13:32:43 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v2]
In-Reply-To: <Cqz6p5sDVHx8qu7KvgfC9QMLxIK9RHCWpqti_E7Vfqg=.e889a288-4835-40c3-aa93-e17d8377973b@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <Cqz6p5sDVHx8qu7KvgfC9QMLxIK9RHCWpqti_E7Vfqg=.e889a288-4835-40c3-aa93-e17d8377973b@github.com>
Message-ID: <F5CCm4IBVTAI3pvVn9uZdYhYgw03GojYM6qy91AgutM=.7ec0f3f1-8dce-4def-a938-2d38266f8e97@github.com>

On Tue, 10 Oct 2023 05:18:34 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

>> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
>> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove unused JavacTemplateDiagnosticsPrinter.java

Hi! Here is a patch that cleans up the conversion by using the JUnit extension in a more canonical way: https://gist.github.com/sormuras/834e2f05b7d8784d70ad63e91b5e2d96

If the patch doesn't apply cleanly, I'll create a PR against your fork and branch - or you grant me write access to your `JUnit_javac_combo` branch.

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

PR Comment: https://git.openjdk.org/jdk/pull/15281#issuecomment-1755433244

From abimpoudis at openjdk.org  Tue Oct 10 13:58:36 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 10 Oct 2023 13:58:36 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v17]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <ZOxj1XxOM1WFYSkhrUiaLtNaSdStNwCNGN9tFASP3wM=.81fb7d4b-2820-4c18-8771-69b48601dcbc@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update name of exactness methods class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/3030dc14..27c2aab6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=15-16

  Stats: 532 lines in 6 files changed: 285 ins; 242 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From jpai at openjdk.org  Tue Oct 10 14:25:40 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Oct 2023 14:25:40 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <BLNhDFMfiSgtCj6kYK9M-26nHUjLuGYokJk4MFH_Lb8=.9b8460fb-3294-4043-9cdf-951c98da2410@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <BLNhDFMfiSgtCj6kYK9M-26nHUjLuGYokJk4MFH_Lb8=.9b8460fb-3294-4043-9cdf-951c98da2410@github.com>
Message-ID: <6_RH8F-br2F5inF2HvTY0LwLliNWnpEyZmZZU1kdVOU=.613ec312-1ca3-4659-9ccf-7c61bb01b7ad@github.com>

On Sun, 8 Oct 2023 05:48:28 GMT, Danny Thomas <duke at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos.
>
> After much head scratching attempting to run the benchmarks for 8309130, I realised this change broke microbenchmarks:
> 
> $ make test TEST="micro:java.lang.ArraysSort"
> Building target 'test' in configuration 'linux-x86_64-server-release'
> ...
> Test selection 'micro:java.lang.ArraysSort', will run:
> * micro:java.lang.ArraysSort
> 
> Running test 'micro:java.lang.ArraysSort'
> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find the resource: /META-INF/BenchmarkList
> 	at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98)
> 	at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124)
> 	at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252)
> 	at org.openjdk.jmh.runner.Runner.run(Runner.java:208)
> 	at org.openjdk.jmh.Main.main(Main.java:71)
> Finished running test 'micro:java.lang.ArraysSort'
> Test report is stored in build/linux-x86_64-server-release/test-results/micro_java_lang_ArraysSort

Hello @DanielThomas, thank you reporting and narrowing down the microbenchmark failures. This is now being addressed in https://bugs.openjdk.org/browse/JDK-8317802.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1755530249

From liach at openjdk.org  Tue Oct 10 14:49:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 10 Oct 2023 14:49:45 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v18]
In-Reply-To: <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
Message-ID: <zeldZnTL_IpN4uFYnDowJr84Pa9nmY5Xqnz1U0U3cgg=.2bb49e78-9ed6-4b90-ab4c-fc9f7e2bf1c0@github.com>

On Tue, 10 Oct 2023 11:29:40 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 348 commits:
> 
>  - Merge branch 'master' into JDK-8308753-preview
>  - added @sealedGraph tags
>  - fixed exception type thrown from CodeImpl
>  - added constraint to throw on an attempt to parse unknown classfile version
>    + test
>  - removed AttributeMapper::validSince
>  - fixed DirectCodeBuilder
>  - improved ClassFile constants javadoc
>  - fixed AnnotationValue::of javadoc
>  - fixed elements javadoc
>  - Typo in BufWriter javadoc
>  - ... and 338 more: https://git.openjdk.org/jdk/compare/ad7a8e86...5e537a86

We need to remove the outdated exports in `BuildMicroBenchmarks.gmk` after the package migration.

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

PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1755601401

From liangchenblue at gmail.com  Tue Oct 10 15:24:32 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 10 Oct 2023 23:24:32 +0800
Subject: condy and enums
In-Reply-To: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
Message-ID: <CABe8uE32ZkRWyC1_Jt0sXTS8VatjkF0ZtMc+YGX+Gh231DcNpA@mail.gmail.com>

Hello Liam,
I think your approach is quite nice. For your information, for non-static
arguments like an invocation, we can compile a static factory method that
returns an enum instance or use ConstantBootstraps.invoke as the non-static
argument's bootstrap method. The invokestatic-putstatic sequence is 6 bytes
as well.

If there are too many arguments, condy bootstrap method arguments may run
into the constant pool size limit, though unlikely.

Condy might be more costly than a plain invocation at runtime compared to
plain new-dup-init sequence, without caching or precomputation involved. We
need to check the initialization performance of these new enums.

For the bootstrapping issue, I've left a comment on your draft PR; I think
it should be controlled via a compiler flag like StringConcat.

Chen Liang

On Tue, Oct 10, 2023 at 6:11?AM Liam Miller-Cushon <cushon at google.com>
wrote:

> Hello,
>
> I'd like to discuss the idea of using constant dynamic in the generated
> code for enums.
>
> The possibility of using condy came up in the review thread for
> JDK-8241798, which implemented a small change to the code generation
> strategy for enums to raise the limit on the number of enum constants. To
> recap, there are limits on the number of constants in an enum imposed by
> the class file format. The constants are represented as static final
> fields, which have to be initialized in the clinit, which eventually runs
> into the 64k method size limit:
>
> https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html
> https://bugs.openjdk.org/browse/JDK-8241798
>
> I did some recent experimentation into using condy to initialize enum
> constants and create the values array. There's a very rough draft here:
> https://github.com/openjdk/jdk/pull/16108
>
> With that change the clinit just contains a ldc/putstatus for each
> constant, which is 6 bytes per constant, raising the limit on the number of
> constants from ~4k today to about 10k.
>
> I am interested in high level feedback about the idea. Does this seem like
> a good use of condy, or a bad use of condy? Are there reasons (performance,
> maintenance, other things I'm not considering) why using condy in this way
> wouldn't be advisable?
>
> One caveat is that it may not be very valuable to raise the limit further.
> Four thousand is already a lot of enum constants. I suspect for many
> domains where it's necessary to represent >4k values, it will eventually
> need to represent >10k values, and that enums are not the best way to model
> those domains. So I wouldn't argue for doing this if there end up being a
> lot of trade-offs, but if the condy approach was appealing in general
> perhaps raising the limit at the same time could be win-win.
>
> Working through the prototype raised some questions about what a
> production quality implementation would look like:
>
> Enums with user-defined constructors are currently only handled if the
> arguments are static constants. What would the right solution be? Perhaps a
> factory method could be synthetized for constants with non-constant
> arguments, so condy could still be used to load them.
>
> The class initializer for MethodHandle transitively loads enums, so having
> enum class initializers use condy creates a cyclic dependency. The
> prototype skips the new strategy for java.base. I could imagine having a
> way to opt specific enums out of the new strategy, but having to maintain
> multiple code generation strategies for enums does not seem very appealing.
> Perhaps there's a way to refactor to break those cycles, or that the lazy
> static final field proposal in JDK-8209964 could help here, or something
> else.
>
> I'm curious what you think,
> Liam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231010/be0b43b0/attachment.htm>

From acobbs at openjdk.org  Tue Oct 10 17:02:37 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 10 Oct 2023 17:02:37 GMT
Subject: RFR: 8317818: Combinatorial explosion during 'this' escape analysis
Message-ID: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>

The `this-escape` analysis stops infinite recursions during the analysis by keeping track of what methods have already been invoked with any given set of current references.

However, it was using the method call site, not the target method itself, for this tracking. This can lead to a combinatorial explosion, for example, if there are multiple recursive calls inside the target method, where we would end up recursing through all possible combinations of call sites before stopping the recursion.

The fix is to key on the target method itself, not on whatever call site.

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

Commit messages:
 - Track 'this-escape' recursion by target method, not by call site.

Changes: https://git.openjdk.org/jdk/pull/16125/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317818
  Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16125/head:pull/16125

PR: https://git.openjdk.org/jdk/pull/16125

From acobbs at openjdk.org  Wed Oct 11 00:51:49 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 11 Oct 2023 00:51:49 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
 [v5]
In-Reply-To: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
Message-ID: <1yLKApWVRpFKmhGyuXNyisDp_k6JZwIx91AweoOsSq0=.6faff436-2daf-4311-b30a-a58a3e554011@github.com>

> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
> 
> This patch explicitly clears any leftover `ExprRef`'s after evaluating a lambda body; this restores the asserted invariant when the lambda body is an expression.
> 
> This also fixes another variant of the same bug caused by certain enhanced `for()` loops. In this case, the leftover `ExprRef` was from evaluating the loop expression. This was just a side-effect of the analyzer failing to override `TreeScanner` to actually assign the loop expression to the loop variable.

Archie Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - Fix regression test class names.
 - Refactor patch to minimize it to just the required bugfix.
 - Fix inadvertent variable renaming.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16001/files
  - new: https://git.openjdk.org/jdk/pull/16001/files/09e42837..043e8fec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16001&range=03-04

  Stats: 15 lines in 2 files changed: 1 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/16001.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16001/head:pull/16001

PR: https://git.openjdk.org/jdk/pull/16001

From archie.cobbs at gmail.com  Wed Oct 11 01:39:32 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 10 Oct 2023 20:39:32 -0500
Subject: Request reviews for 'this-escape' bug fixes
Message-ID: <CANSoFxvcftmB2NCcn2YTHCsbpHx_J8KpR2=4+DAdR4+04GQrVA@mail.gmail.com>

The 'this-escape' warning is new in JDK 21 and since the release a couple
of bugs have trickled in that ought to be fixed because they cause
compilation to fail.

I'd appreciate anyone who could review these for me. They are both fairly
simple but I'm happy to explain them further if needed.

JDK-8317336 - Assertion error thrown during 'this' escape analysis
https://git.openjdk.org/jdk/pull/16001

JDK-8317818 - Combinatorial explosion during 'this' escape analysis
https://github.com/openjdk/jdk/pull/16125

Thanks!
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231010/d2590895/attachment.htm>

From asotona at openjdk.org  Wed Oct 11 07:17:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Oct 2023 07:17:04 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete exports from BuildMicrobenchmark.gmk

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/5e537a86..37371955

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=17-18

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Wed Oct 11 07:17:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 11 Oct 2023 07:17:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v18]
In-Reply-To: <zeldZnTL_IpN4uFYnDowJr84Pa9nmY5Xqnz1U0U3cgg=.2bb49e78-9ed6-4b90-ab4c-fc9f7e2bf1c0@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
 <zeldZnTL_IpN4uFYnDowJr84Pa9nmY5Xqnz1U0U3cgg=.2bb49e78-9ed6-4b90-ab4c-fc9f7e2bf1c0@github.com>
Message-ID: <KuAU-LCSLBvrGo-gIMO4u0WCIgX4e3x9ul7YzK50hT0=.9f3fbe84-ede2-44b9-a901-d1e6e3a7974f@github.com>

On Tue, 10 Oct 2023 14:46:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> We need to remove the outdated exports in `BuildMicroBenchmarks.gmk` after the package migration.

Removed, good catch, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/15706#issuecomment-1756993662

From abimpoudis at openjdk.org  Wed Oct 11 08:09:03 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Oct 2023 08:09:03 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v18]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <x-UiODIT3sOaMegpOd_M1Dd-HgQm2z3CJyZ62xKOP4Q=.94e47037-b702-4251-b08a-72430121e22f@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Update name of exactness methods class
 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
   Co-authored-by: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - Fixing error conditions, tweaking tests.
 - Attempting to improve reported errors.
 - Add comment for TypePairs
 - ... and 13 more: https://git.openjdk.org/jdk/compare/68beac56...3c0d85e9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/27c2aab6..3c0d85e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=16-17

  Stats: 1754 lines in 30 files changed: 800 ins; 788 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From cstein at openjdk.org  Wed Oct 11 10:22:11 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 11 Oct 2023 10:22:11 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v2]
In-Reply-To: <F5CCm4IBVTAI3pvVn9uZdYhYgw03GojYM6qy91AgutM=.7ec0f3f1-8dce-4def-a938-2d38266f8e97@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <Cqz6p5sDVHx8qu7KvgfC9QMLxIK9RHCWpqti_E7Vfqg=.e889a288-4835-40c3-aa93-e17d8377973b@github.com>
 <F5CCm4IBVTAI3pvVn9uZdYhYgw03GojYM6qy91AgutM=.7ec0f3f1-8dce-4def-a938-2d38266f8e97@github.com>
Message-ID: <UrWXN4dhwfvQd7ErF80xQ62bOHl4qoJOIYqHOWwThBQ=.f5c2e0fe-a23d-4392-926f-337520aad0f1@github.com>

On Tue, 10 Oct 2023 13:29:45 GMT, Christian Stein <cstein at openjdk.org> wrote:

> I'll create a PR against your fork and branch

So I did: https://github.com/xqoasis/jdk/pull/1

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

PR Comment: https://git.openjdk.org/jdk/pull/15281#issuecomment-1757336753

From abimpoudis at openjdk.org  Wed Oct 11 14:48:48 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Oct 2023 14:48:48 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v4]
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <2zeqTfDRUNUZHuCJXwaumAoE-SlE2neEv0AKfDz2XYU=.7da6a633-c7c8-4a1f-9d43-0b1b5ab0fb32@github.com>

> This PR finalizes the feature of unnamed variables and patterns.

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

 - Add test with multi-catch
 - Merge branch 'master' into unnamed
 - Address review by @mcimadamore
 - Address review by @lahodaj
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/630b128e..ccbfbd4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=02-03

  Stats: 99666 lines in 2717 files changed: 41569 ins; 19343 del; 38754 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From abimpoudis at openjdk.org  Wed Oct 11 15:43:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 11 Oct 2023 15:43:19 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/3c0d85e9..d06b2172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=17-18

  Stats: 18 lines in 2 files changed: 10 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From vromero at openjdk.org  Wed Oct 11 17:40:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Oct 2023 17:40:50 GMT
Subject: RFR: 8317818: Combinatorial explosion during 'this' escape
 analysis
In-Reply-To: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
References: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
Message-ID: <I7Oz1Gev1gLceQ7kcxPR0SW4e8EIJ3ZijSieoh1mK5w=.29a41fe3-c2d5-4a9b-97cb-e6a377151a44@github.com>

On Tue, 10 Oct 2023 16:55:22 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The `this-escape` analysis stops infinite recursions during the analysis by keeping track of what methods have already been invoked with any given set of current references.
> 
> However, it was using the method call site, not the target method itself, for this tracking. This can lead to a combinatorial explosion, for example, if there are multiple recursive calls inside the target method, where we would end up recursing through all possible combinations of call sites before stopping the recursion.
> 
> The fix is to key on the target method itself, not on whatever call site.

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16125#pullrequestreview-1672044756

From vromero at openjdk.org  Wed Oct 11 18:59:38 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 11 Oct 2023 18:59:38 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
 [v5]
In-Reply-To: <1yLKApWVRpFKmhGyuXNyisDp_k6JZwIx91AweoOsSq0=.6faff436-2daf-4311-b30a-a58a3e554011@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
 <1yLKApWVRpFKmhGyuXNyisDp_k6JZwIx91AweoOsSq0=.6faff436-2daf-4311-b30a-a58a3e554011@github.com>
Message-ID: <IlqQ4SrwVioaQDTHzOS9w4-2mei04mS2Di3GTG7ewzg=.6afb3bcb-ac9d-4924-99b2-5d1209869d4b@github.com>

On Wed, 11 Oct 2023 00:51:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
>> 
>> This patch explicitly clears any leftover `ExprRef`'s after evaluating a lambda body; this restores the asserted invariant when the lambda body is an expression.
>> 
>> This also fixes another variant of the same bug caused by certain enhanced `for()` loops. In this case, the leftover `ExprRef` was from evaluating the loop expression. This was just a side-effect of the analyzer failing to override `TreeScanner` to actually assign the loop expression to the loop variable (that will be fixed later in another patch).
>
> Archie Cobbs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix regression test class names.
>  - Refactor patch to minimize it to just the required bugfix.
>  - Fix inadvertent variable renaming.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16001#pullrequestreview-1672290431

From acobbs at openjdk.org  Wed Oct 11 20:22:12 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 11 Oct 2023 20:22:12 GMT
Subject: RFR: 8317336: Assertion error thrown during 'this' escape analysis
 [v5]
In-Reply-To: <1yLKApWVRpFKmhGyuXNyisDp_k6JZwIx91AweoOsSq0=.6faff436-2daf-4311-b30a-a58a3e554011@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
 <1yLKApWVRpFKmhGyuXNyisDp_k6JZwIx91AweoOsSq0=.6faff436-2daf-4311-b30a-a58a3e554011@github.com>
Message-ID: <vTzbScTcWHb1yaFa8HgzlK77PPnxZsu0IpGQwmmT0jw=.5f2aec11-b4fc-4e86-a918-844d94501b15@github.com>

On Wed, 11 Oct 2023 00:51:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
>> 
>> This patch explicitly clears any leftover `ExprRef`'s after evaluating a lambda body; this restores the asserted invariant when the lambda body is an expression.
>> 
>> This also fixes another variant of the same bug caused by certain enhanced `for()` loops. In this case, the leftover `ExprRef` was from evaluating the loop expression. This was just a side-effect of the analyzer failing to override `TreeScanner` to actually assign the loop expression to the loop variable (that will be fixed later in another patch).
>
> Archie Cobbs has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Fix regression test class names.
>  - Refactor patch to minimize it to just the required bugfix.
>  - Fix inadvertent variable renaming.

@vicente-romero-oracle, thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/16001#issuecomment-1758472743

From cushon at google.com  Wed Oct 11 23:03:08 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 11 Oct 2023 16:03:08 -0700
Subject: condy and enums
In-Reply-To: <bc21a757-328c-4cf3-8687-3641b3da698c@oracle.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
 <bc21a757-328c-4cf3-8687-3641b3da698c@oracle.com>
Message-ID: <CAL4QsgvUwXF5jpmDuUw10dxnegXgJyY2MjbpU8G_YyWSJ7Uxrw@mail.gmail.com>

Hi Maurizio, thanks for the comments!

I am still kind of on the fence about this one, as you say.

I collected some data from Google's codebase, and a majority of enum
constants would be able to use condy:
* 71% of enum declarations have no explicit constructors that take
parameters.
* 80% percent of expressions used as arguments to enum constructors are
constants.
* The most common non-constant expressions used as arguments to enum
constructors include static factory methods (e.g. `List.of(...)`,
`Map.of(...)`, Optional.of(...)`). I also saw a number of static field
accesses (e.g. `BigDecimal.ZERO`). None of those individual examples
account for more than 1% of the total, and there was a long tail.

What are your thoughts on how often we'd want to be able to use this path,
before it was worth supporting?

On Tue, Oct 10, 2023 at 3:34?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> Hi Liam,
> the overall idea seem fine. I'm a bit on the fence (as I think you
> already are) when I try to assess whether adding the extra complexity is
> worth it here. On the one hand, the code we have today is not very
> compact, but the javac translation strategy is quite uniform, and can
> deal with both enum construction and custom enums (e.g. enums which
> define their own bodies). The approach proposed here, while it's more
> compact for the case where an enum has no parameters (or where the
> parameters are not constant), it has to contain some fallback logic for
> the more general case, so the resulting lowering code becomes a little
> bit more cryptic to understand, and maintain (going forward).
>
> Do you have some data re. how many enum construction can be optimized
> with this approach? Trying to think about code I've seen in the past,
> the assumption that enum construction parameters are constant doesn't
> strike me as too unrealistic, so I would expect that a lot of enums out
> there could be optimized by this path (in which case I'd be more willing
> to consider it).
>
> Thanks for the great work!
> Maurizio
>
>
> On 09/10/2023 22:45, Liam Miller-Cushon wrote:
> > Hello,
> >
> > I'd like to discuss the idea of using constant dynamic in the
> > generated code for enums.
> >
> > The possibility of using condy came up in the review thread for
> > JDK-8241798, which implemented a small change to the code generation
> > strategy for enums to raise the limit on the number of enum constants.
> > To recap, there are limits on the number of constants in an enum
> > imposed by the class file format. The constants are represented as
> > static final fields, which have to be initialized in the clinit, which
> > eventually runs into the 64k method size limit:
> >
> > https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html
> > https://bugs.openjdk.org/browse/JDK-8241798
> >
> > I did some recent experimentation into using condy to initialize enum
> > constants and create the values array. There's a very rough draft
> > here: https://github.com/openjdk/jdk/pull/16108
> >
> > With that change the clinit just contains a ldc/putstatus for each
> > constant, which is 6 bytes per constant, raising the limit on the
> > number of constants from ~4k today to about 10k.
> >
> > I am interested in high level feedback about the idea. Does this seem
> > like a good use of condy, or a bad use of condy? Are there reasons
> > (performance, maintenance, other things I'm not considering) why using
> > condy in this way wouldn't be advisable?
> >
> > One caveat is that it may not be very valuable to raise the limit
> > further. Four thousand is already a lot of enum constants. I suspect
> > for many domains where it's necessary to represent >4k values, it will
> > eventually need to represent >10k values, and that enums are not the
> > best way to model those domains. So I wouldn't argue for doing this if
> > there end up being a lot of trade-offs, but if the condy approach was
> > appealing in general perhaps raising the limit at the same time could
> > be win-win.
> >
> > Working through the prototype raised some questions about what a
> > production quality implementation would look like:
> >
> > Enums with user-defined constructors are currently only handled if the
> > arguments are static constants. What would the right solution be?
> > Perhaps a factory method could be synthetized for constants with
> > non-constant arguments, so condy could still be used to load them.
> >
> > The class initializer for MethodHandle transitively loads enums, so
> > having enum class initializers use condy creates a cyclic dependency.
> > The prototype skips the new strategy for java.base. I could imagine
> > having a way to opt specific enums out of the new strategy, but having
> > to maintain multiple code generation strategies for enums does not
> > seem very appealing. Perhaps there's a way to refactor to break those
> > cycles, or that the lazy static final field proposal in JDK-8209964
> > could help here, or something else.
> >
> > I'm curious what you think,
> > Liam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231011/dd63adaa/attachment-0001.htm>

From cushon at google.com  Wed Oct 11 23:08:00 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Wed, 11 Oct 2023 16:08:00 -0700
Subject: condy and enums
In-Reply-To: <CABe8uE32ZkRWyC1_Jt0sXTS8VatjkF0ZtMc+YGX+Gh231DcNpA@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
 <CABe8uE32ZkRWyC1_Jt0sXTS8VatjkF0ZtMc+YGX+Gh231DcNpA@mail.gmail.com>
Message-ID: <CAL4QsgtG80Xpbqds1iHtb=9NDTtMJLbfPTSQsZHzzSsgtAC+-w@mail.gmail.com>

Thanks! Responses inline,

On Tue, Oct 10, 2023 at 8:24?AM - <liangchenblue at gmail.com> wrote:

> Hello Liam,
> I think your approach is quite nice. For your information, for non-static
> arguments like an invocation, we can compile a static factory method that
> returns an enum instance or use ConstantBootstraps.invoke as the non-static
> argument's bootstrap method. The invokestatic-putstatic sequence is 6 bytes
> as well.
>
> If there are too many arguments, condy bootstrap method arguments may run
> into the constant pool size limit, though unlikely.
>

Using static factory methods seems like it could be a nice way to use condy
more consistently for language levels that support it, instead of switching
back and forth between the two strategies depending on whether or not
constant arguments were present.


> Condy might be more costly than a plain invocation at runtime compared to
> plain new-dup-init sequence, without caching or precomputation involved. We
> need to check the initialization performance of these new enums.
>

I collected some simple performance measurements of an enum with 4000
constants with and without the new strategy. The results were pretty
stable, and condy came out ~0.07s faster. The startup performance
implications definitely deserve more investigation and scrutiny, but those
initial numbers seem encouraging.

The benchmark was roughly:

enum C {
  C1,
  // <snip>
  C4000;
  public static void main(String[] args) {
    System.out.println(C.values().length);
  }
}


> For the bootstrapping issue, I've left a comment on your draft PR; I think
> it should be controlled via a compiler flag like StringConcat.
>

Done, thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231011/5558ee4d/attachment.htm>

From maurizio.cimadamore at oracle.com  Wed Oct 11 23:35:37 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 12 Oct 2023 00:35:37 +0100
Subject: condy and enums
In-Reply-To: <CAL4QsgvUwXF5jpmDuUw10dxnegXgJyY2MjbpU8G_YyWSJ7Uxrw@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
 <bc21a757-328c-4cf3-8687-3641b3da698c@oracle.com>
 <CAL4QsgvUwXF5jpmDuUw10dxnegXgJyY2MjbpU8G_YyWSJ7Uxrw@mail.gmail.com>
Message-ID: <e0662c7a-6572-47c0-b948-3ec8e0230b20@oracle.com>


On 12/10/2023 00:03, Liam Miller-Cushon wrote:
> Hi Maurizio, thanks for the comments!
>
> I am still kind of on the fence about this one, as you say.
>
> I collected some data from Google's codebase, and a majority of enum 
> constants would be able to use condy:
> *?71% of enum declarations have no explicit constructors that take 
> parameters.
> * 80% percent of expressions used as arguments to enum constructors 
> are constants.
> *?The most common non-constant expressions used as arguments to enum 
> constructors include static factory methods (e.g. `List.of(...)`, 
> `Map.of(...)`, Optional.of(...)`). I also saw a number of static field 
> accesses (e.g. `BigDecimal.ZERO`). None of those individual examples 
> account for more than 1% of the total, and there was a long tail.
>
> What are your thoughts on how often we'd want to be able to use this 
> path, before it was worth supporting?

Hi Liam
Thanks for the great data (as always).

I think these numbers make the evidence for your case a little stronger, 
as it does seem that the footprint will be reduced in the majority of cases.

On balance, I believe it's something that might be worth pursuing.

As pointed out in other emails, we'd need to keep an eye on the startup 
impact (because of condy), as well as possible bootstrap issues when 
using such a feature in a module like java.base. For instance, the 
indified string concat support has an option so that it's turned off 
when compiling java.base.

Cheers
Maurizio



>
> On Tue, Oct 10, 2023 at 3:34?AM Maurizio Cimadamore 
> <maurizio.cimadamore at oracle.com> wrote:
>
>     Hi Liam,
>     the overall idea seem fine. I'm a bit on the fence (as I think you
>     already are) when I try to assess whether adding the extra
>     complexity is
>     worth it here. On the one hand, the code we have today is not very
>     compact, but the javac translation strategy is quite uniform, and can
>     deal with both enum construction and custom enums (e.g. enums which
>     define their own bodies). The approach proposed here, while it's more
>     compact for the case where an enum has no parameters (or where the
>     parameters are not constant), it has to contain some fallback
>     logic for
>     the more general case, so the resulting lowering code becomes a
>     little
>     bit more cryptic to understand, and maintain (going forward).
>
>     Do you have some data re. how many enum construction can be optimized
>     with this approach? Trying to think about code I've seen in the past,
>     the assumption that enum construction parameters are constant doesn't
>     strike me as too unrealistic, so I would expect that a lot of
>     enums out
>     there could be optimized by this path (in which case I'd be more
>     willing
>     to consider it).
>
>     Thanks for the great work!
>     Maurizio
>
>
>     On 09/10/2023 22:45, Liam Miller-Cushon wrote:
>     > Hello,
>     >
>     > I'd like to discuss the idea of using constant dynamic in the
>     > generated code for enums.
>     >
>     > The possibility of using condy came up in the review thread for
>     > JDK-8241798, which implemented a small change to the code
>     generation
>     > strategy for enums to raise the limit on the number of enum
>     constants.
>     > To recap, there are limits on the number of constants in an enum
>     > imposed by the class file format. The constants are represented as
>     > static final fields, which have to be initialized in the clinit,
>     which
>     > eventually runs into the 64k method size limit:
>     >
>     >
>     https://mail.openjdk.org/pipermail/compiler-dev/2020-March/014413.html
>     > https://bugs.openjdk.org/browse/JDK-8241798
>     >
>     > I did some recent experimentation into using condy to initialize
>     enum
>     > constants and create the values array. There's a very rough draft
>     > here: https://github.com/openjdk/jdk/pull/16108
>     <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/16108__;!!ACWV5N9M2RV99hQ!LfR6LWykI9T8OOPyuCoGQDZPUBAgWFkAT22M6yh7r8c4Nyscjyx9K8iQBKFut-J6SSLbCkwfDV_zdClD7xULwQ$>
>     >
>     > With that change the clinit just contains a ldc/putstatus for each
>     > constant, which is 6 bytes per constant, raising the limit on the
>     > number of constants from ~4k today to about 10k.
>     >
>     > I am interested in high level feedback about the idea. Does this
>     seem
>     > like a good use of condy, or a bad use of condy? Are there reasons
>     > (performance, maintenance, other things I'm not considering) why
>     using
>     > condy in this way wouldn't be advisable?
>     >
>     > One caveat is that it may not be very valuable to raise the limit
>     > further. Four thousand is already a lot of enum constants. I
>     suspect
>     > for many domains where it's necessary to represent >4k values,
>     it will
>     > eventually need to represent >10k values, and that enums are not
>     the
>     > best way to model those domains. So I wouldn't argue for doing
>     this if
>     > there end up being a lot of trade-offs, but if the condy
>     approach was
>     > appealing in general perhaps raising the limit at the same time
>     could
>     > be win-win.
>     >
>     > Working through the prototype raised some questions about what a
>     > production quality implementation would look like:
>     >
>     > Enums with user-defined constructors are currently only handled
>     if the
>     > arguments are static constants. What would the right solution be?
>     > Perhaps a factory method could be synthetized for constants with
>     > non-constant arguments, so condy could still be used to load them.
>     >
>     > The class initializer for MethodHandle transitively loads enums, so
>     > having enum class initializers use condy creates a cyclic
>     dependency.
>     > The prototype skips the new strategy for java.base. I could imagine
>     > having a way to opt specific enums out of the new strategy, but
>     having
>     > to maintain multiple code generation strategies for enums does not
>     > seem very appealing. Perhaps there's a way to refactor to break
>     those
>     > cycles, or that the lazy static final field proposal in JDK-8209964
>     > could help here, or something else.
>     >
>     > I'm curious what you think,
>     > Liam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231012/038b98ef/attachment-0001.htm>

From john.r.rose at oracle.com  Thu Oct 12 01:01:45 2023
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Oct 2023 18:01:45 -0700
Subject: condy and enums
In-Reply-To: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
Message-ID: <A448C7CD-0133-4869-AD37-B19FA6CF756D@oracle.com>

On 9 Oct 2023, at 14:45, Liam Miller-Cushon wrote:

>  I'd like to discuss the idea of using constant dynamic in the 
> generated code for enums.

Although I?m fond of condy, I don?t think this is in its sweet spot. 
  Condy is good for fine-grained lazy evaluation, at the granularity of 
bytecode instructions.  But for setting up an enum, the granularity is 
really the whole class, and all you need per enum member is a 
stereotyped action to build the enum instance, followed by putstatic.

I would consider using this code shape for the `<clinit>`:

```
? for each member:
iconst {nextenumordinal}
invokestatic $make$(I)L{thisenumclass};
putstatic {nextenumfield}
?
return
```

That would get you to 7k enums, by factoring the mess of creation into a 
single helper method, or 8k enums with a helper method for each block of 
256.

The single helper method `$make$` would in many cases be very simple, 
but might be a large `tableswitch` with varying code on each branch.  
The single helper can be factored into multiple sub-helpers, if code 
size grows beyond the bytecode size limit.  (It will do that, if each 
branch has to contain different code.)  So instead you?d have to 
generate a sub-helper function for each block of (say) 1000 enums, and a 
decision tree at the top level (`$make$`) to decide which sub-helper to 
call.  All straightforward and also annoyingly unproductive, since large 
enums are very rare.

Replacing the invokestatic by ldc/condy gives you marginally more enums, 
but at the cost of exploding the size (and complexity and runtime 
effort) of your constant pool.  When calculating complexity, don?t 
just count bytecodes in one method (`<clinit>`) but rather estimate the 
classfile size.  That means taking into account the number and size of 
constant pool entries, as well as the number and size of bytecodes (also 
method declarations).

If you want to do decisively better, and support tens of thousands of 
enum members, you can do so by bolding making `<clinit>` be constant in 
size.  That can be accomplished by using a reflective computation to 
build the enums and patch them into the static finals.  You could use 
varhandles or old reflection, but I?d just go straight to Unsafe and 
make this a JDK service function, to avoid bootstrapping issues.

The service function would iterate over the enum class?s fields, 
detect which ones were enum elements, and call a helper function created 
by the enum class:

```
public static void initializeEnumClass(Lookup enumClassLU, MethodHandle 
enumMemberCreator) {
   int ordinal = 0;
   if (!enumClassLU.hasPrivateAccess())  throw (IAE);
   Class<? extends Enum> ec = 
enumClassLU.lookupClass().asSubClass(Enum.class);
   for (Field f : ec.getDeclaredFields()) {  //order significant here
     if (f is an enum member) {
       Object e = enumMemberCreator.invokeExact(f, ordinal++);
       // next stuff can be done more directly by Unsafe
       assert(f.get(null) == null);  //caller resp.
       f.setAccessible(true);
       f.set(null, e);
     }
   }
}
```

The creation of the values array should be done in `<clinit>`, as well, 
or as a condy (yes, that?s a good usage of condy!) and cloned as a 
fresh copy for each call to `values()`.  And it can be done reflectively 
as well.  Just iterate over all the fields and store them into the 
array.  (Use the `ordinal()` as the array index, or just assert that the 
fields are in the correct order already.)

With those two adjustments, to bind enums and build the values array 
reflectively, your enum would be limited only by the maximum size of the 
constant pool.  That is, you could have up to about 65k enums (but not 
the whole 2^16).

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231011/def0e064/attachment.htm>

From john.r.rose at oracle.com  Thu Oct 12 01:07:59 2023
From: john.r.rose at oracle.com (John Rose)
Date: Wed, 11 Oct 2023 18:07:59 -0700
Subject: condy and enums
In-Reply-To: <A448C7CD-0133-4869-AD37-B19FA6CF756D@oracle.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
 <A448C7CD-0133-4869-AD37-B19FA6CF756D@oracle.com>
Message-ID: <5A27EA8F-0B81-44F6-B71A-8CCEE2438C46@oracle.com>

P.S. I trust it is clear how the single service method below would be 
used in the `<clinit>` of each client enum.  One other thing occurred to 
me:  Enums which have bootstrap entanglements with the MethodHandle 
class would need special treatment.  For that reason, it might be better 
to not pass the argument `MethodHandle enumMemberCreator` but rather 
just call a private static method of a fixed name and signature, within 
the same enum.  That can be easily done with method handles, if those 
are ?on line?, but can also be done with core reflection, which 
boots up sooner.

On 11 Oct 2023, at 18:01, John Rose wrote:

> ```
> public static void initializeEnumClass(Lookup enumClassLU, 
> MethodHandle enumMemberCreator) {
>   int ordinal = 0;
>   if (!enumClassLU.hasPrivateAccess())  throw (IAE);
>   Class<? extends Enum> ec = 
> enumClassLU.lookupClass().asSubClass(Enum.class);
>   for (Field f : ec.getDeclaredFields()) {  //order significant here
>     if (f is an enum member) {
>       Object e = enumMemberCreator.invokeExact(f, ordinal++);
>       // next stuff can be done more directly by Unsafe
>       assert(f.get(null) == null);  //caller resp.
>       f.setAccessible(true);
>       f.set(null, e);
>     }
>   }
> }
> ```
>
> The creation of the values array should be done in `<clinit>`, as 
> well, or as a condy (yes, that?s a good usage of condy!) and cloned 
> as a fresh copy for each call to `values()`.  And it can be done 
> reflectively as well.  Just iterate over all the fields and store them 
> into the array.  (Use the `ordinal()` as the array index, or just 
> assert that the fields are in the correct order already.)
>
> With those two adjustments, to bind enums and build the values array 
> reflectively, your enum would be limited only by the maximum size of 
> the constant pool.  That is, you could have up to about 65k enums (but 
> not the whole 2^16).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231011/74a6da3e/attachment-0001.htm>

From ihse at openjdk.org  Thu Oct 12 10:27:37 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Oct 2023 10:27:37 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
Message-ID: <HOWFpv3FCSqAv4b-AjswiPg3BKH0eeUUEa-wDxK3R7M=.afe62baf-e9ee-4cb6-8e3b-759749194058@github.com>

On Wed, 11 Oct 2023 07:17:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete exports from BuildMicrobenchmark.gmk

make/test/BuildMicrobenchmark.gmk line 99:

> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
> 98:         --add-exports java.base/sun.invoke.util=ALL-UNNAMED \
> 99:         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \

Just checking: do we really need `jdk.internal.classfile.impl`? (It might have been added in by someone a bit sloppily just adding all jdk.internal.classfile modules.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356612666

From asotona at openjdk.org  Thu Oct 12 10:43:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Oct 2023 10:43:27 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <HOWFpv3FCSqAv4b-AjswiPg3BKH0eeUUEa-wDxK3R7M=.afe62baf-e9ee-4cb6-8e3b-759749194058@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
 <HOWFpv3FCSqAv4b-AjswiPg3BKH0eeUUEa-wDxK3R7M=.afe62baf-e9ee-4cb6-8e3b-759749194058@github.com>
Message-ID: <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>

On Thu, 12 Oct 2023 10:23:56 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed obsolete exports from BuildMicrobenchmark.gmk
>
> make/test/BuildMicrobenchmark.gmk line 99:
> 
>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
>> 98:         --add-exports java.base/sun.invoke.util=ALL-UNNAMED \
>> 99:         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \
> 
> Just checking: do we really need `jdk.internal.classfile.impl`? (It might have been added in by someone a bit sloppily just adding all jdk.internal.classfile modules.)

One of the benchmarks is focused on stack maps generator, which is not directly exposed through the API. We can remove this one and keep just the API-based benchmarks if it an issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356629635

From ihse at openjdk.org  Thu Oct 12 10:51:31 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 12 Oct 2023 10:51:31 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
 <HOWFpv3FCSqAv4b-AjswiPg3BKH0eeUUEa-wDxK3R7M=.afe62baf-e9ee-4cb6-8e3b-759749194058@github.com>
 <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>
Message-ID: <XVWncd1owysPo9dCwrcDdk4E8AHUjCVWkeY9ep-4fY4=.de765a60-16fd-49f2-a547-f4856abdb260@github.com>

On Thu, 12 Oct 2023 10:40:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> make/test/BuildMicrobenchmark.gmk line 99:
>> 
>>> 97:     JAVAC_FLAGS := --add-exports java.base/sun.security.util=ALL-UNNAMED \
>>> 98:         --add-exports java.base/sun.invoke.util=ALL-UNNAMED \
>>> 99:         --add-exports java.base/jdk.internal.classfile.impl=ALL-UNNAMED \
>> 
>> Just checking: do we really need `jdk.internal.classfile.impl`? (It might have been added in by someone a bit sloppily just adding all jdk.internal.classfile modules.)
>
> One of the benchmarks is focused on stack maps generator, which is not directly exposed through the API. We can remove this one and keep just the API-based benchmarks if it an issue.

No, it is not an issue per se. If we need to benchmark internal code, that's totally fine. I just wanted to check so we did not pass unnecessary arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356638601

From mcimadamore at openjdk.org  Thu Oct 12 11:18:47 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 12 Oct 2023 11:18:47 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
Message-ID: <Kb0v5ZgK_MKWBwxZHkH19R7dF_Sg3gzN3I1JTpJ-U80=.261bdda7-6781-4417-9682-1e9f200e88ad@github.com>

On Wed, 11 Oct 2023 07:17:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
>> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
>> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
>> 
>> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
>> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
>> 
>> Online javadoc is available at:?
>> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
>> 
>> In addition to the primary transition to preview, this pull request also includes:
>> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
>> - A new preview feature, `CLASSFILE_API`, has been added.
>> - Buildsystem tool required a little patch to support annotated modules.
>> - All JDK modules using the Classfile API are newly participating in the preview.
>> - All tests that use the Classfile API now have preview enabled.
>> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
>> 
>> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
>> 
>> Please review this pull request to help the Classfile API turn into a preview.
>> 
>> Any comments are welcome.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removed obsolete exports from BuildMicrobenchmark.gmk

src/java.base/share/classes/java/lang/classfile/package-info.java line 259:

> 257:  * the classfile building process.
> 258:  * <p>
> 259:  * Syntax validation is applied during symbolic descriptors construction.

I would drop `syntax` - and just use `Validation`

src/java.base/share/classes/java/lang/classfile/package-info.java line 265:

> 263:  * <p>
> 264:  * Using symbolic descriptors assures the right serial form selection by
> 265:  * the ClassFile API library. For example a class name is stored in its internal

I find this comment still very hard to parse. There is a lot of terminology here thrown to the reader (internal form, class descriptor, serial form), and very little explanation of which is which. I get the general idea that, if I use a `ClassDesc`, the API will take care to convert that to the right form, depending on the context - but it feels there's too much text, and too few examples to ground that text.

src/java.base/share/classes/java/lang/classfile/package-info.java line 278:

> 276:  * constant pool entries to avoid any form of syntax validation or conversion.
> 277:  * Constant pool entries can be constructed from raw values, with no additional
> 278:  * syntactic checks, conversions or validations. In the following example is

`syntactic checks` and `validation` feel the same thing. If there's some validation that is materially different from a syntactic check that is important for the reader to grasp, then spell it out. Otherwise leave it out and remain more general.

src/java.base/share/classes/java/lang/classfile/package-info.java line 401:

> 399:  *
> 400:  * <h3>Transformation handling of unknown classfile elements</h3>
> 401:  * Future JDK releases may introduce new classfile elements, not known at the

Maybe this is more direct/punchy?

`Custom classfile transformations might be unaware of classfile elements introduced by future JDK releases.`

src/java.base/share/classes/java/lang/classfile/package-info.java line 403:

> 401:  * Future JDK releases may introduce new classfile elements, not known at the
> 402:  * development time of a custom transformation code.
> 403:  * To achieve deterministic stability of transformations running on future JDK

This para seems largely redundant. Perhaps you can merge with the next? E.g. "To achieve deterministic stability, classfile transforms interested ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356662662
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356661342
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356663577
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356666225
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356667448

From asotona at openjdk.org  Thu Oct 12 15:28:46 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Oct 2023 15:28:46 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v20]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <y4l-Nkd4YZRjSMsRB35vQrl-DrKgtktXAvMMYGzTM80=.412353b1-56f3-4153-be75-f6b68f2917a2@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  package info javadoc improvements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15706/files
  - new: https://git.openjdk.org/jdk/pull/15706/files/37371955..edc13bac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=18-19

  Stats: 24 lines in 1 file changed: 0 ins; 10 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From asotona at openjdk.org  Thu Oct 12 15:28:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 12 Oct 2023 15:28:55 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v19]
In-Reply-To: <Kb0v5ZgK_MKWBwxZHkH19R7dF_Sg3gzN3I1JTpJ-U80=.261bdda7-6781-4417-9682-1e9f200e88ad@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <RiTGTCP0_bjGZlqWi3GW4yuv2yl8RNKM2NjrBdAnaEA=.1851cbf6-fa52-42c4-b9fa-ed8ca404d482@github.com>
 <Kb0v5ZgK_MKWBwxZHkH19R7dF_Sg3gzN3I1JTpJ-U80=.261bdda7-6781-4417-9682-1e9f200e88ad@github.com>
Message-ID: <DcsF7MUUDbBa43BbfNvC0uQv5JgZFXOaZluCDUcX1y4=.7b309a21-26bd-4ef2-b5ee-9d25d884f99a@github.com>

On Thu, 12 Oct 2023 11:11:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   removed obsolete exports from BuildMicrobenchmark.gmk
>
> src/java.base/share/classes/java/lang/classfile/package-info.java line 259:
> 
>> 257:  * the classfile building process.
>> 258:  * <p>
>> 259:  * Syntax validation is applied during symbolic descriptors construction.
> 
> I would drop `syntax` - and just use `Validation`

Yes, applied, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 265:
> 
>> 263:  * <p>
>> 264:  * Using symbolic descriptors assures the right serial form selection by
>> 265:  * the ClassFile API library. For example a class name is stored in its internal
> 
> I find this comment still very hard to parse. There is a lot of terminology here thrown to the reader (internal form, class descriptor, serial form), and very little explanation of which is which. I get the general idea that, if I use a `ClassDesc`, the API will take care to convert that to the right form, depending on the context - but it feels there's too much text, and too few examples to ground that text.

I've tried to rephrase the paragraph and simplify it, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 278:
> 
>> 276:  * constant pool entries to avoid any form of syntax validation or conversion.
>> 277:  * Constant pool entries can be constructed from raw values, with no additional
>> 278:  * syntactic checks, conversions or validations. In the following example is
> 
> `syntactic checks` and `validation` feel the same thing. If there's some validation that is materially different from a syntactic check that is important for the reader to grasp, then spell it out. Otherwise leave it out and remain more general.

Right, fixed, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 401:
> 
>> 399:  *
>> 400:  * <h3>Transformation handling of unknown classfile elements</h3>
>> 401:  * Future JDK releases may introduce new classfile elements, not known at the
> 
> Maybe this is more direct/punchy?
> 
> `Custom classfile transformations might be unaware of classfile elements introduced by future JDK releases.`

More clear, thanks.

> src/java.base/share/classes/java/lang/classfile/package-info.java line 403:
> 
>> 401:  * Future JDK releases may introduce new classfile elements, not known at the
>> 402:  * development time of a custom transformation code.
>> 403:  * To achieve deterministic stability of transformations running on future JDK
> 
> This para seems largely redundant. Perhaps you can merge with the next? E.g. "To achieve deterministic stability, classfile transforms interested ..."

Yes, merged according to the suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356989724
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356989504
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356989983
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356990585
PR Review Comment: https://git.openjdk.org/jdk/pull/15706#discussion_r1356991173

From acobbs at openjdk.org  Thu Oct 12 16:54:51 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Oct 2023 16:54:51 GMT
Subject: Integrated: 8317336: Assertion error thrown during 'this' escape
 analysis
In-Reply-To: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
References: <WtXLAwHk6NjreXssQZQ4cWUobwrQrKNJDnNNEgDMh9Q=.98f1cde8-6a80-4c74-b537-1a5ab1d02c95@github.com>
Message-ID: <X6L8muJPsSY8w-z206u_TD3ec1QHfwzsHMMrQyduqIM=.24ce9d51-f05c-4cda-b26f-dda8c90819e4@github.com>

On Sun, 1 Oct 2023 19:48:46 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The 'this' escape analyzer was assuming that lambas could always be treated like blocks, in the sense that we can assume a block can never end in a plain expression. This assumption is not true for lambda's of the form `() -> foo` which do exactly that. In the case that `foo` was `this`, an assertion failure would ensue.
> 
> This patch explicitly clears any leftover `ExprRef`'s after evaluating a lambda body; this restores the asserted invariant when the lambda body is an expression.
> 
> This also fixes another variant of the same bug caused by certain enhanced `for()` loops. In this case, the leftover `ExprRef` was from evaluating the loop expression. This was just a side-effect of the analyzer failing to override `TreeScanner` to actually assign the loop expression to the loop variable (that will be fixed later in another patch).

This pull request has now been integrated.

Changeset: a8473b70
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8473b70797ef8fa0704774bfadbd84cb33a1d53
Stats:     25 lines in 2 files changed: 23 ins; 0 del; 2 mod

8317336: Assertion error thrown during 'this' escape analysis

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/16001

From acobbs at openjdk.org  Thu Oct 12 17:01:56 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Oct 2023 17:01:56 GMT
Subject: RFR: 8317818: Combinatorial explosion during 'this' escape
 analysis [v2]
In-Reply-To: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
References: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
Message-ID: <9gf96bs5tBW3woZkth7SecSv26hKcv4MdTqbFud3GDQ=.3bd3690a-dc28-4038-a21c-2bcbf924e00c@github.com>

> The `this-escape` analysis stops infinite recursions during the analysis by keeping track of what methods have already been invoked with any given set of current references.
> 
> However, it was using the method call site, not the target method itself, for this tracking. This can lead to a combinatorial explosion, for example, if there are multiple recursive calls inside the target method, where we would end up recursing through all possible combinations of call sites before stopping the recursion.
> 
> The fix is to key on the target method itself, not on whatever call site.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge remote-tracking branch 'upstream/master' into JDK-8317818
 - Track 'this-escape' recursion by target method, not by call site.

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

Changes: https://git.openjdk.org/jdk/pull/16125/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16125&range=01
  Stats: 32 lines in 2 files changed: 30 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16125/head:pull/16125

PR: https://git.openjdk.org/jdk/pull/16125

From vromero at openjdk.org  Thu Oct 12 18:15:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 18:15:32 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
Message-ID: <xmkK16jbGycLEOguNHdKk9aZffWDb5uWa4IS7M551_Y=.f3e23675-3108-481c-82b9-37f7a5c4b49e@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 45:

> 43:     private ExactConversionsSupport() { }
> 44: 
> 45:      /** Exactness method from int to byte

nit: there seems to be an indentation issue in these javadoc, the subsequent lines should be aligned with the first one. What I see in other javadocs is that we don't write in the first line after the `/**` and instead the javadoc starts in the subsequent line.

side: would it make sense to generate this file mechanically? seems like a great candidate for that

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357212078

From vromero at openjdk.org  Thu Oct 12 20:45:23 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 20:45:23 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
Message-ID: <drb8XEdroVzBtUovSI2auUOTKRI89354Af9hQKdFXXg=.89001e48-fe4f-4580-92ef-814c34d66269@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 366:

> 364:             (selectorType.equals(int.class) && targetType.equals(Integer.class)))
> 365:             return true;
> 366:         else if (selectorType.equals(targetType) || (selectorType.equals(byte.class) && !targetType.equals(char.class)  ||

this code reminds me of some tricks we did to simplify similar code in the past, see `com.sun.tools.javac.code.TypeTag` and related:  `com.sun.tools.javac.code.TypeTag.NumericClasses` and method `com.sun.tools.javac.code.TypeTag::isSubRangeOf` and how it is used to determine if a numerical type is subtype of another numerical type. These tricks could be reused here, but up to you. I could also be done in a future refactoring.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357396699

From acobbs at openjdk.org  Thu Oct 12 20:58:17 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Oct 2023 20:58:17 GMT
Subject: RFR: 8317818: Combinatorial explosion during 'this' escape
 analysis [v2]
In-Reply-To: <I7Oz1Gev1gLceQ7kcxPR0SW4e8EIJ3ZijSieoh1mK5w=.29a41fe3-c2d5-4a9b-97cb-e6a377151a44@github.com>
References: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
 <I7Oz1Gev1gLceQ7kcxPR0SW4e8EIJ3ZijSieoh1mK5w=.29a41fe3-c2d5-4a9b-97cb-e6a377151a44@github.com>
Message-ID: <fmibKNuQMHTVYmSPpBFfatfqeW34c_d-XFv9-SbVx0E=.45ec3447-436b-4601-b6ad-efced00c2499@github.com>

On Wed, 11 Oct 2023 17:38:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8317818
>>  - Track 'this-escape' recursion by target method, not by call site.
>
> looks good

@vicente-romero-oracle thanks for the reviews. Please resubmit this one - the two fixes conflicted on the unit test file so this one had to be merged & pushed again. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/16125#issuecomment-1760352691

From vromero at openjdk.org  Thu Oct 12 22:40:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 22:40:22 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
Message-ID: <3CZrL-oopwafV6fQq-i-Jrbq-5eJ4bOzH52za4USkfs=.77c6db7c-6b0e-45b2-9c60-d66aba5d66a3@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5055:

> 5053:         return (source.isPrimitive() && target.isPrimitive()) &&
> 5054:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
> 5055:                         (source.hasTag(SHORT) && (target.hasTag(INT) || target.hasTag(LONG) || target.hasTag(FLOAT) || target.hasTag(DOUBLE)))||

this code can also be simplified as suggested for similar code in SwitchBootstraps, actually here you have access to the infra already in TypeTag and can leverage it.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2910:

> 2908:     }
> 2909: 
> 2910:     public void visitTypeTest(JCInstanceOf tree) {

would it make sense to document how the generated code should look like?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357407958
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357439742

From vromero at openjdk.org  Thu Oct 12 22:42:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 12 Oct 2023 22:42:25 GMT
Subject: RFR: 8317818: Combinatorial explosion during 'this' escape
 analysis [v2]
In-Reply-To: <I7Oz1Gev1gLceQ7kcxPR0SW4e8EIJ3ZijSieoh1mK5w=.29a41fe3-c2d5-4a9b-97cb-e6a377151a44@github.com>
References: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
 <I7Oz1Gev1gLceQ7kcxPR0SW4e8EIJ3ZijSieoh1mK5w=.29a41fe3-c2d5-4a9b-97cb-e6a377151a44@github.com>
Message-ID: <VI_bT418poDhpUrhcsXJ0cHJl0ivYDXeoWvpyUN05Dg=.71683466-8614-4ab6-a5fb-fc035850f69a@github.com>

On Wed, 11 Oct 2023 17:38:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into JDK-8317818
>>  - Track 'this-escape' recursion by target method, not by call site.
>
> looks good

> @vicente-romero-oracle thanks for the reviews. Please resubmit this one - the two fixes conflicted on the unit test file so this one had to be merged & pushed again. Thanks.

sure

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

PR Comment: https://git.openjdk.org/jdk/pull/16125#issuecomment-1760464897

From acobbs at openjdk.org  Thu Oct 12 22:42:27 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 12 Oct 2023 22:42:27 GMT
Subject: Integrated: 8317818: Combinatorial explosion during 'this' escape
 analysis
In-Reply-To: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
References: <CTBTyxr9IE8OAYz39_SDrm9sLWmLFdxRwfJFNgBZyd4=.660841e7-522d-41dc-b95c-e602ae56adae@github.com>
Message-ID: <IZ9pKDOORft739VoHsrTJwJZ_L-OimdJlLsRbOJXQY0=.752790eb-be06-4fda-bd86-3bb6fb1c6d1e@github.com>

On Tue, 10 Oct 2023 16:55:22 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> The `this-escape` analysis stops infinite recursions during the analysis by keeping track of what methods have already been invoked with any given set of current references.
> 
> However, it was using the method call site, not the target method itself, for this tracking. This can lead to a combinatorial explosion, for example, if there are multiple recursive calls inside the target method, where we would end up recursing through all possible combinations of call sites before stopping the recursion.
> 
> The fix is to key on the target method itself, not on whatever call site.

This pull request has now been integrated.

Changeset: 17535c34
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/17535c34bc7853f8e73dfdec2c4da49d78b37bea
Stats:     32 lines in 2 files changed: 30 ins; 0 del; 2 mod

8317818: Combinatorial explosion during 'this' escape analysis

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/16125

From xqoasis at openjdk.org  Fri Oct 13 00:15:17 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Fri, 13 Oct 2023 00:15:17 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v3]
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <TyiHCoB8kAB5pdk3T23Sb_PeGrvgsz1qwxWbLXjv8s4=.82579490-70db-4f4e-b29e-8680d8c4ddba@github.com>

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

Qing Xiao has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #1 from sormuras/pr/15281
   
   Cleanup conversion. Thanks Christian!
 - Cleanup conversion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15281/files
  - new: https://git.openjdk.org/jdk/pull/15281/files/5f9f0f60..b4393108

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=01-02

  Stats: 290 lines in 13 files changed: 74 ins; 119 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/15281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15281/head:pull/15281

PR: https://git.openjdk.org/jdk/pull/15281

From xqoasis at openjdk.org  Fri Oct 13 00:51:19 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Fri, 13 Oct 2023 00:51:19 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v4]
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <BQWmZAjKdMi3_407fHmUnKN3BB5zcLFP0X_d4x4V8_M=.8f0947f3-2e69-4606-b5c7-5ff7c1cf4f7a@github.com>

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

Qing Xiao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Merge branch 'master' into JUnit_javac_combo
 - Merge pull request #1 from sormuras/pr/15281
   
   Cleanup conversion. Thanks Christian!
 - Cleanup conversion
 - remove unused JavacTemplateDiagnosticsPrinter.java
 - Update test/langtools/lib/combo/TEST.properties
   
   Co-authored-by: Christian Stein <sormuras at gmail.com>
 - Modified years
 - Modified tests which extends tools in /combo/tools/javac/combo. Added DiagnosticPrinter.
 - Modified tests which extends tools in /combo/tools/javac/combo
 - Use JUnit Jupiter API in langtools/lib tests instead of TestNG. (Under /combo/tools/javac/combo/)

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

Changes: https://git.openjdk.org/jdk/pull/15281/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=03
  Stats: 580 lines in 17 files changed: 204 ins; 107 del; 269 mod
  Patch: https://git.openjdk.org/jdk/pull/15281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15281/head:pull/15281

PR: https://git.openjdk.org/jdk/pull/15281

From xqoasis at openjdk.org  Fri Oct 13 03:05:38 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Fri, 13 Oct 2023 03:05:38 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v5]
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Try to solve whitespace error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15281/files
  - new: https://git.openjdk.org/jdk/pull/15281/files/87f69f42..500a8a4c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=03-04

  Stats: 57 lines in 2 files changed: 0 ins; 0 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/15281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15281/head:pull/15281

PR: https://git.openjdk.org/jdk/pull/15281

From vromero at openjdk.org  Fri Oct 13 05:28:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Oct 2023 05:28:28 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
Message-ID: <-7dHm7aTGSEtcaNvl1RNNz2hgAbSVT6ljg-h9yRaMPc=.d1dafc1b-4828-497f-8c62-595060213a3f@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

test/langtools/tools/javac/patterns/PrimitivePatternsComboTest.java line 2:

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

nit: year should be 2023 only

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1357760556

From rgiulietti at openjdk.org  Fri Oct 13 09:36:21 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 13 Oct 2023 09:36:21 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
Message-ID: <MylmnZRl3s8NNVh6PFLrxlVD23Cp8WdpLC4JZT-kBk0=.2aaceba6-e060-4707-a9e5-de921a5505df@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 51:

> 49:      *
> 50:      * */
> 51:     public static boolean intToByteExact(int n)      {return n == (int)(byte)n;}

These ones seem more _conversions_ than _tests_.
To me, `intToByteExact(int)` looks more like a request to convert an `int` to a `byte`, rather than a check to see whether the argument lies in the `byte` range.
Pure methods returning `boolean` are often named like `isIntToByteExact(int)` or the like (`is*()`, `has*()`, etc.)

I know: choosing good, speaking, and evocative names is one of the hardest problem in computer science.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1358027977

From cstein at openjdk.org  Fri Oct 13 10:20:22 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 13 Oct 2023 10:20:22 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v5]
In-Reply-To: <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>
Message-ID: <9ek_wnZFcQ8G5Tu1_eSm6xTRsLRx0rW1Lvi_hjbbRP4=.7eab0c4d-7629-455f-a8d2-dc06e5fa8f6d@github.com>

On Fri, 13 Oct 2023 03:05:38 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

>> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
>> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Try to solve whitespace error

Ups. Thank you for fixing the CRLF line endings in the new files.

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

PR Comment: https://git.openjdk.org/jdk/pull/15281#issuecomment-1761272161

From cstein at openjdk.org  Fri Oct 13 10:28:45 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 13 Oct 2023 10:28:45 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v5]
In-Reply-To: <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>
Message-ID: <Bo9LKAndiqgndGpAi_dRJENpi0dlEikbXZYCYdR8Wdk=.a643a049-9968-4283-a407-6f804ade5319@github.com>

On Fri, 13 Oct 2023 03:05:38 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

>> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
>> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Try to solve whitespace error

Looks good to me - and thanks for your patience!

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

Marked as reviewed by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/15281#pullrequestreview-1676193119

From vromero at openjdk.org  Fri Oct 13 16:04:45 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Oct 2023 16:04:45 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body [v3]
In-Reply-To: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
Message-ID: <x0ychpO4aR-RuAgzSFbmSR_cbo5P4uBdTKSy3Yx36cM=.38026e41-9f4d-4ff5-9cef-ed975e6905bf@github.com>

> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
> 
> 
> enum T {
>   ONE("");
> 
>   T(String one);  // missing constructor body
> 
>   final String one;
> }
> 
> the fix is a one liner
> TIA

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

 - Merge branch 'master' into JDK-8305971
 - addressing review comments
 - 8305971: NPE in JavacProcessingEnvironment for missing enum constructor body

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15974/files
  - new: https://git.openjdk.org/jdk/pull/15974/files/2902b04d..222287d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=01-02

  Stats: 24206 lines in 808 files changed: 12768 ins; 5698 del; 5740 mod
  Patch: https://git.openjdk.org/jdk/pull/15974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15974/head:pull/15974

PR: https://git.openjdk.org/jdk/pull/15974

From cstein at openjdk.org  Fri Oct 13 17:05:11 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 13 Oct 2023 17:05:11 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v5]
In-Reply-To: <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <LYk3IK50Vcm3dZoDQ-U4T0S31Py4x5t9jlsDOZD-sFA=.91a0909f-f97e-4142-9084-b797934adabf@github.com>
Message-ID: <E48Xc7OdnPufROvT2e35U1E8FSzvSyP0R0EcfzjyX6E=.81e47cf5-b4c9-4083-9c68-c66f499b0eac@github.com>

On Fri, 13 Oct 2023 03:05:38 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

>> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
>> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Try to solve whitespace error

test/langtools/tools/javac/records/RecordCompilationTests.java line 1320:

> 1318:     void testCheckInitializationOrderInCompactConstructor() throws Exception {
> 1319:         int putField1 = -1;
> 1320:         int putField2 = -1;

Suggestion:

        FieldInstruction putField1 = null;
        FieldInstruction putField2 = null;


Was the conversion from FieldInstruction to int intended or a by-product of merging?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15281#discussion_r1358515419

From xqoasis at openjdk.org  Fri Oct 13 17:16:14 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Fri, 13 Oct 2023 17:16:14 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v6]
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <crFWTr9-TG4ZPGaAfSR73DclXmryTt-_LZv01JVwMto=.c52f96e3-0591-42c8-975e-5db5f836ba0c@github.com>

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  Update test/langtools/tools/javac/records/RecordCompilationTests.java
  
  Co-authored-by: Christian Stein <sormuras at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15281/files
  - new: https://git.openjdk.org/jdk/pull/15281/files/500a8a4c..e13576bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15281&range=04-05

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

PR: https://git.openjdk.org/jdk/pull/15281

From cushon at google.com  Fri Oct 13 19:55:02 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Fri, 13 Oct 2023 12:55:02 -0700
Subject: condy and enums
In-Reply-To: <5A27EA8F-0B81-44F6-B71A-8CCEE2438C46@oracle.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
 <A448C7CD-0133-4869-AD37-B19FA6CF756D@oracle.com>
 <5A27EA8F-0B81-44F6-B71A-8CCEE2438C46@oracle.com>
Message-ID: <CAL4QsguBm=H+a5vvWUUEj+0RQJtChGVrosvQnDTAKPNmtD5pMw@mail.gmail.com>

Thanks for the comments, that is a very neat idea!

I was labouring under a misunderstanding of what the verifier constraints
are. My understanding is that at the Java language level, each static final
has to be definitely assigned at the end of the static initializer (JLS
8.3.1.2), but the VM has fewer restrictions. Is the only constraint that
putstatic is only allowed to write to static final fields inside clinit,
and there is no requirement that static finals are definitely assigned in
the clinit, so using Unsafe to initialize the fields is fair game?

I have a rough draft of your approach here:
https://github.com/openjdk/jdk/pull/16191

* It uses reflection and Unsafe.staticFieldOffset for the JVM method.

* I took a short-cut and disabled generation of values() array. It would be
possible to split the values() array across multiple methods, but that
would still require additional constant pool entries, and as you described
the constant pool size ends up being the limiting factor. I think the
values() array could still be a good use of indy or condy.

With that prototype, I was able to generate an enum with ~32K constants.
Each enum name currently uses two constant pool entries (a Utf8 and String
entry for the name). Perhaps there's a way to get that down to one entry,
and get to ~65k enums.

I collected some preliminary performance data: with 4000 constants, cold
start time is ~400ms with the new codegen and ~700ms without. With ~32K
constants, startup takes a full ~17s. From some initial investigation, most
of that time is spent in Class.getDeclaredFields and
Unsafe.staticFieldOffset.

This has been fun and educational. it also adds complexity to javac, and
may not be a clear improvement for non-pathological enums that don't have
many thousands of entries.

Do you think it could be worth pursuing?

On Wed, Oct 11, 2023 at 6:08?PM John Rose <john.r.rose at oracle.com> wrote:

> P.S. I trust it is clear how the single service method below would be used
> in the <clinit> of each client enum. One other thing occurred to me:
> Enums which have bootstrap entanglements with the MethodHandle class would
> need special treatment. For that reason, it might be better to not pass the
> argument MethodHandle enumMemberCreator but rather just call a private
> static method of a fixed name and signature, within the same enum. That can
> be easily done with method handles, if those are ?on line?, but can also be
> done with core reflection, which boots up sooner.
>
> On 11 Oct 2023, at 18:01, John Rose wrote:
>
> ```
> public static void initializeEnumClass(Lookup enumClassLU, MethodHandle
> enumMemberCreator) {
> int ordinal = 0;
> if (!enumClassLU.hasPrivateAccess()) throw (IAE);
> Class<? extends Enum> ec =
> enumClassLU.lookupClass().asSubClass(Enum.class);
> for (Field f : ec.getDeclaredFields()) { //order significant here
> if (f is an enum member) {
> Object e = enumMemberCreator.invokeExact(f, ordinal++);
> // next stuff can be done more directly by Unsafe
> assert(f.get(null) == null); //caller resp.
> f.setAccessible(true);
> f.set(null, e);
> }
> }
> }
> ```
>
> The creation of the values array should be done in `<clinit>`, as well, or
> as a condy (yes, that?s a good usage of condy!) and cloned as a fresh copy
> for each call to `values()`. And it can be done reflectively as well. Just
> iterate over all the fields and store them into the array. (Use the
> `ordinal()` as the array index, or just assert that the fields are in the
> correct order already.)
>
> With those two adjustments, to bind enums and build the values array
> reflectively, your enum would be limited only by the maximum size of the
> constant pool. That is, you could have up to about 65k enums (but not the
> whole 2^16).
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231013/c5f2b04c/attachment.htm>

From john.r.rose at oracle.com  Fri Oct 13 22:59:08 2023
From: john.r.rose at oracle.com (John Rose)
Date: Fri, 13 Oct 2023 15:59:08 -0700
Subject: condy and enums
In-Reply-To: <CAL4QsguBm=H+a5vvWUUEj+0RQJtChGVrosvQnDTAKPNmtD5pMw@mail.gmail.com>
References: <CAL4Qsgtbkvy3pBfStXfyWXj_ba2dbOXzHGjS_ecihnYEy4TCnA@mail.gmail.com>
 <A448C7CD-0133-4869-AD37-B19FA6CF756D@oracle.com>
 <5A27EA8F-0B81-44F6-B71A-8CCEE2438C46@oracle.com>
 <CAL4QsguBm=H+a5vvWUUEj+0RQJtChGVrosvQnDTAKPNmtD5pMw@mail.gmail.com>
Message-ID: <9C8EA3D5-80F8-4B49-B26F-D37E98DC989E@oracle.com>

On 13 Oct 2023, at 12:55, Liam Miller-Cushon wrote:

> Thanks for the comments, that is a very neat idea!
>
> I was labouring under a misunderstanding of what the verifier 
> constraints
> are. My understanding is that at the Java language level, each static 
> final
> has to be definitely assigned at the end of the static initializer 
> (JLS
> 8.3.1.2), but the VM has fewer restrictions. Is the only constraint 
> that
> putstatic is only allowed to write to static final fields inside 
> clinit,
> and there is no requirement that static finals are definitely assigned 
> in
> the clinit, so using Unsafe to initialize the fields is fair game?

Yes, that is the case.

> I have a rough draft of your approach here:
> https://github.com/openjdk/jdk/pull/16191
>
> * It uses reflection and Unsafe.staticFieldOffset for the JVM method.
>
> * I took a short-cut and disabled generation of values() array. It 
> would be
> possible to split the values() array across multiple methods, but that
> would still require additional constant pool entries, and as you 
> described
> the constant pool size ends up being the limiting factor. I think the
> values() array could still be a good use of indy or condy.

Yes, condy would work.  The values method would then be generated like 
this:

```
ldc Condy{makeValuesArrayBuilder} : MethodHandle
invokevirtual {MethodHandle::invoke()ThisEnum[]}
areturn
```

Or, a java.lang.ClassValue could be used, and the Enum::values method,
defined just once, would root around in reflective stuff once to set up
the CV.  That?s a moral equivalent of condy, but ?at a distance?.

Or, indy could be used quite directly:

```
invokedynamic  {makeValuesArrayBuilder} : ()ThisEnum[]
areturn
```

I do NOT recommend binding a condy constant to an array.

The reason is that such an array is not in a position to be optimized
by the JIT.  Arrays are by default mutable, and they are treated
as constant only in certain ?stable? places such as in the body
of a list created by `List::of`.  I would accumulate and store
the original source of all clones of the values arrays in a list,
not an array, and make sure the list is immutable (marked stable
in its array state).

>
> With that prototype, I was able to generate an enum with ~32K 
> constants.
> Each enum name currently uses two constant pool entries (a Utf8 and 
> String
> entry for the name). Perhaps there's a way to get that down to one 
> entry,
> and get to ~65k enums.

Yes, there is.  Use reflection to infer the strings.  Don?t access 
them
from the CP via ldc (or as BSM arguments).

> I collected some preliminary performance data: with 4000 constants, 
> cold
> start time is ~400ms with the new codegen and ~700ms without. With 
> ~32K
> constants, startup takes a full ~17s. From some initial investigation, 
> most
> of that time is spent in Class.getDeclaredFields and
> Unsafe.staticFieldOffset.

The problem with core reflection is that it is kind of bulky and slow.
I was going to suggest short-circuiting through an internal API that
uses MemberName but I see there is not one present.  Funny, I thought
I wrote it for JSR 292, but maybe it was GC-ed somehow.

So you may need a sequence of strings to drive the reflective queries,
if you want to avoid all the reflective overheads.  You could derive
a sequence of strings from a single string (or a small number of
max-length strings concatenated) that contains all the field names
in sequence.  That?s O(1) CP entries.  Then you could call the
MemberName query API for single-field queries, mimicing the way it
is used in the Lookup API to build field access method handles.

I?m going into these very internal details just to show what would
be required, as a JDK engineer, to build a properly performant
service method that could iterate the fields of an enum and
initialize them properly.

For prototypes, core reflect is just fine.  But it will not be as
fast as using the off-label internal APIs such as Unsafe and
MemberName.

> This has been fun and educational. it also adds complexity to javac, 
> and
> may not be a clear improvement for non-pathological enums that don't 
> have
> many thousands of entries.
>
> Do you think it could be worth pursuing?

Actually, no, until there is a compelling use case for more than a few
thousand enum members, but (of course) less than 65K or so.

Like you, I found this fun and educational.  It?s a thought exercise
in using metaprogramming (method handle and lookups) instead of bytecode
churning.

There are better applications of metaprogramming, such as string concat,
lambda generation, and (I presume) pattern-switch code generation.

? John

> On Wed, Oct 11, 2023 at 6:08?PM John Rose <john.r.rose at oracle.com> 
> wrote:
>
>> P.S. I trust it is clear how the single service method below would be 
>> used
>> in the <clinit> of each client enum. One other thing occurred to me:
>> Enums which have bootstrap entanglements with the MethodHandle class 
>> would
>> need special treatment. For that reason, it might be better to not 
>> pass the
>> argument MethodHandle enumMemberCreator but rather just call a 
>> private
>> static method of a fixed name and signature, within the same enum. 
>> That can
>> be easily done with method handles, if those are ?on line?, but 
>> can also be
>> done with core reflection, which boots up sooner.
>>
>> On 11 Oct 2023, at 18:01, John Rose wrote:
>>
>> ```
>> public static void initializeEnumClass(Lookup enumClassLU, 
>> MethodHandle
>> enumMemberCreator) {
>> int ordinal = 0;
>> if (!enumClassLU.hasPrivateAccess()) throw (IAE);
>> Class<? extends Enum> ec =
>> enumClassLU.lookupClass().asSubClass(Enum.class);
>> for (Field f : ec.getDeclaredFields()) { //order significant here
>> if (f is an enum member) {
>> Object e = enumMemberCreator.invokeExact(f, ordinal++);
>> // next stuff can be done more directly by Unsafe
>> assert(f.get(null) == null); //caller resp.
>> f.setAccessible(true);
>> f.set(null, e);
>> }
>> }
>> }
>> ```
>>
>> The creation of the values array should be done in `<clinit>`, as 
>> well, or
>> as a condy (yes, that?s a good usage of condy!) and cloned as a 
>> fresh copy
>> for each call to `values()`. And it can be done reflectively as well. 
>> Just
>> iterate over all the fields and store them into the array. (Use the
>> `ordinal()` as the array index, or just assert that the fields are in 
>> the
>> correct order already.)
>>
>> With those two adjustments, to bind enums and build the values array
>> reflectively, your enum would be limited only by the maximum size of 
>> the
>> constant pool. That is, you could have up to about 65k enums (but not 
>> the
>> whole 2^16).
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231013/c8100a77/attachment-0001.htm>

From vromero at openjdk.org  Fri Oct 13 23:09:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Oct 2023 23:09:22 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body [v4]
In-Reply-To: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
Message-ID: <dXtgKgrlpRyOpUDjHigefIlFNyRiXAe_hNFcUmxaHjA=.3636483d-bb85-4ef2-94ec-02fb3ad3fb74@github.com>

> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
> 
> 
> enum T {
>   ONE("");
> 
>   T(String one);  // missing constructor body
> 
>   final String one;
> }
> 
> the fix is a one liner
> TIA

Vicente Romero has updated the pull request incrementally with two additional commits since the last revision:

 - missed change in test
 - minor change to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15974/files
  - new: https://git.openjdk.org/jdk/pull/15974/files/222287d6..3620f2e6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=02-03

  Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/15974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15974/head:pull/15974

PR: https://git.openjdk.org/jdk/pull/15974

From vromero at openjdk.org  Fri Oct 13 23:16:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 13 Oct 2023 23:16:39 GMT
Subject: RFR: 8305971: NPE in JavacProcessingEnvironment for missing enum
 constructor body [v5]
In-Reply-To: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
Message-ID: <JfBrDSzPFfM7NNKpIJ8Q9WXQnOaMlYbKuqGIHg_HZeQ=.3b383b1e-777f-4c15-9d7e-a55c75addec2@github.com>

> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
> 
> 
> enum T {
>   ONE("");
> 
>   T(String one);  // missing constructor body
> 
>   final String one;
> }
> 
> the fix is a one liner
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  minor test change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15974/files
  - new: https://git.openjdk.org/jdk/pull/15974/files/3620f2e6..eb76ab40

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15974&range=03-04

  Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15974/head:pull/15974

PR: https://git.openjdk.org/jdk/pull/15974

From vromero at openjdk.org  Sat Oct 14 22:13:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 14 Oct 2023 22:13:31 GMT
Subject: Integrated: 8305971: NPE in JavacProcessingEnvironment for missing
 enum constructor body
In-Reply-To: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
References: <nir49MVZ2P7pwMRf32OusUFVpSYNa1kADM_07QM1tuo=.d0952f49-c9a4-4fa8-957c-b3c9277497e6@github.com>
Message-ID: <fuWSIbQLg4aBZfwaDEPL5KI404oq6kBDzeWC9jcqJ1k=.8218e771-fc3b-400f-8288-f2122591a888@github.com>

On Thu, 28 Sep 2023 21:23:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this simple fix that is averting a NPE in JavacProcessingEnvironment if a an annotation processor is used while compiling this erroneous code:
> 
> 
> enum T {
>   ONE("");
> 
>   T(String one);  // missing constructor body
> 
>   final String one;
> }
> 
> the fix is a one liner
> TIA

This pull request has now been integrated.

Changeset: 01ea1eff
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01ea1eff66e43f106640ecfd19fadf2c8245a1ad
Stats:     132 lines in 2 files changed: 131 ins; 0 del; 1 mod

8305971: NPE in JavacProcessingEnvironment for missing enum constructor body

Reviewed-by: darcy

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

PR: https://git.openjdk.org/jdk/pull/15974

From forax at univ-mlv.fr  Mon Oct 16 08:27:31 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 16 Oct 2023 10:27:31 +0200 (CEST)
Subject: Regression: accessing a private method through a type variable
Message-ID: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>

Hello,
There is a regression in recent versions of javac.
javac 21 allows to access a private method through a type variable, here T::asString.

public class TDotToString {
  class Bar() {
    private String asString() {
      return "bar";
    }
  }

  static <T extends Bar> String foo(List<T> list) {
    return list.stream().map(T::asString).collect(Collectors.joining());
  }
}

Both IntelliJ and Eclipse emit an error in this case.

And javac 8 emits
  TDotToString.java:12: error: invalid method reference
    return list.stream().map(T::asString).collect(Collectors.joining());
                             ^
  cannot find symbol
    symbol:   method asString()
    location: bound of type variable T
  where T is a type-variable:
    T extends TDotToString.Bar declared in method <T>foo(List<T>)
1 error

regards,
R?mi

From asotona at openjdk.org  Mon Oct 16 08:32:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Oct 2023 08:32:04 GMT
Subject: RFR: 8313613: Use JUnit in langtools/lib tests [v6]
In-Reply-To: <crFWTr9-TG4ZPGaAfSR73DclXmryTt-_LZv01JVwMto=.c52f96e3-0591-42c8-975e-5db5f836ba0c@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
 <crFWTr9-TG4ZPGaAfSR73DclXmryTt-_LZv01JVwMto=.c52f96e3-0591-42c8-975e-5db5f836ba0c@github.com>
Message-ID: <0pBrVj0UD5RjyS2skt1Yw2KQ_i1ibad5dVwcvmonkI8=.0849fb6f-27a7-4c46-872c-3d6dd7be40ae@github.com>

On Fri, 13 Oct 2023 17:16:14 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

>> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
>> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.
>
> Qing Xiao has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/langtools/tools/javac/records/RecordCompilationTests.java
>   
>   Co-authored-by: Christian Stein <sormuras at gmail.com>

Looks good, thank you.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15281#pullrequestreview-1679408350

From cstein at openjdk.org  Mon Oct 16 08:33:55 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 16 Oct 2023 08:33:55 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs
Message-ID: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>

Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.

The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.

To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.

### Open Ends

- [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)

### OpenJDK's Demo Programs

OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:

- [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
- [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
- [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
- [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
- [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
- [x] `src/demo/share/jfc/Notepad/Notepad.java`
- [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
- [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
- [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
- [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
- [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
- [x] `src/demo/share/jfc/TableExample/TableExample3.java`
- [x] `src/demo/share/jfc/TableExample/TableExample4.java`
- [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

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

Commit messages:
 - Require package name of the program to match the end of its source file path
 - Revert change to add `ALL-MODULE-PATH`in source launch mode
 - Move test program to directory matching its package name
 - In source launch mode, add all modules on the module path by default
 - 8306914: Launch Multi-File Source-Code Programs

Changes: https://git.openjdk.org/jdk/pull/13712/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306914
  Stats: 2368 lines in 25 files changed: 2338 ins; 11 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13712/head:pull/13712

PR: https://git.openjdk.org/jdk/pull/13712

From darcy at openjdk.org  Mon Oct 16 08:33:55 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 16 Oct 2023 08:33:55 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <SvG1GIGL1uBzg6mT2M57tDbAu4jToJUacpOKhfRlrN4=.67a5a47c-01f7-44f1-9220-389026c8a3a1@github.com>

On Fri, 28 Apr 2023 08:00:36 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

A few high-level comments after an initial read over the PR:

I recommend declared the new top-level cases final (or sealed) where possible.

I suggest leaving some "breadcrumbs" in other option-handling locations in the code base to provide maintenance reminders that if a "relevant" option is added, it should be added to the RelevantJavacOptions list.

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

PR Comment: https://git.openjdk.org/jdk/pull/13712#issuecomment-1548925681

From sundararajan.athijegannathan at oracle.com  Mon Oct 16 09:40:00 2023
From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan)
Date: Mon, 16 Oct 2023 09:40:00 +0000
Subject: Regression: accessing a private method through a type variable
In-Reply-To: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
References: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>

fwiw, this compile from at least JDK 11 onwards:

import java.util.*;
import java.util.stream.*;

public class TDotToString {
  class Bar {
    private String asString() {
      return "bar";
    }
  }

  static <T extends Bar> String foo(List<T> list) {
    return list.stream().map(T::asString).collect(Collectors.joining());
  }
}

javac from 1.8.0 does issue error as mentioned by Remi.


-Sundar
________________________________
From: compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: 16 October 2023 13:57
To: compiler-dev <compiler-dev at openjdk.org>
Subject: Regression: accessing a private method through a type variable

Hello,
There is a regression in recent versions of javac.
javac 21 allows to access a private method through a type variable, here T::asString.

public class TDotToString {
  class Bar() {
    private String asString() {
      return "bar";
    }
  }

  static <T extends Bar> String foo(List<T> list) {
    return list.stream().map(T::asString).collect(Collectors.joining());
  }
}

Both IntelliJ and Eclipse emit an error in this case.

And javac 8 emits
  TDotToString.java:12: error: invalid method reference
    return list.stream().map(T::asString).collect(Collectors.joining());
                             ^
  cannot find symbol
    symbol:   method asString()
    location: bound of type variable T
  where T is a type-variable:
    T extends TDotToString.Bar declared in method <T>foo(List<T>)
1 error

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231016/6a38e338/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Mon Oct 16 12:15:08 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 16 Oct 2023 13:15:08 +0100
Subject: Regression: accessing a private method through a type variable
In-Reply-To: <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>
References: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>
Message-ID: <c1fbee53-765a-441e-92b3-d39b5709cb06@oracle.com>

I recall fixing this a long time ago:


https://bugs.openjdk.org/browse/JDK-6711619


Now, the test case mentioned in that bug is still correctly rejected by 
javac. Furhermore, a similar test:


```
class X<E extends X<E>> {
 ???????????? private static int m() { return 1; }
 ???????????? int f() {
 ???????????????????? return E.m();
 ???????????? }
 ??? }
```


Also fails to compile with 21/22.


```
Test.java:5: error: m() has private access in X
 ???????????????????? return E.m();
 ???????????????????????????? ^
1 error

```


Trying to manipulate Remi's example, it seems the regression only has to 
do with method refreences whose receiver is a type variable.


Here's a minimal reproducer:


```
import java.util.function.*;

class Test {
 ? private String asString() {
 ??? return "bar";
 ? }

 ? static <T extends Test> Function<T, String> foo() {
 ??? return T::asString;
 ? }
}
```

I filed a bug:


https://bugs.openjdk.org/browse/JDK-6711619


Thanks
Maurizio


On 16/10/2023 10:40, Sundararajan Athijegannathan wrote:
> fwiw, this compile from at least JDK 11 onwards:
>
> import java.util.*;
> import java.util.stream.*;
>
> public class TDotToString {
> ? class Bar {
> ? ? private String asString() {
> ? ? ? return "bar";
> ? ? }
> ? }
>
> ? static <T extends Bar> String foo(List<T> list) {
> ? ? return list.stream().map(T::asString).collect(Collectors.joining());
> ? }
> }
>
> javac from 1.8.0 does issue error as mentioned by Remi.
>
>
> -Sundar
> ------------------------------------------------------------------------
> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of Remi 
> Forax <forax at univ-mlv.fr>
> *Sent:* 16 October 2023 13:57
> *To:* compiler-dev <compiler-dev at openjdk.org>
> *Subject:* Regression: accessing a private method through a type variable
> Hello,
> There is a regression in recent versions of javac.
> javac 21 allows to access a private method through a type variable, 
> here T::asString.
>
> public class TDotToString {
> ? class Bar() {
> ??? private String asString() {
> ????? return "bar";
> ??? }
> ? }
>
> ? static <T extends Bar> String foo(List<T> list) {
> ??? return list.stream().map(T::asString).collect(Collectors.joining());
> ? }
> }
>
> Both IntelliJ and Eclipse emit an error in this case.
>
> And javac 8 emits
> ? TDotToString.java:12: error: invalid method reference
> ??? return list.stream().map(T::asString).collect(Collectors.joining());
> ???????????????????????????? ^
> ? cannot find symbol
> ??? symbol:?? method asString()
> ??? location: bound of type variable T
> ? where T is a type-variable:
> ??? T extends TDotToString.Bar declared in method <T>foo(List<T>)
> 1 error
>
> regards,
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231016/1d56ef2a/attachment.htm>

From jlahoda at openjdk.org  Mon Oct 16 13:35:33 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 16 Oct 2023 13:35:33 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <s-rTg6Wxi-nfqWz_RpGhBJWXlK4hcIQvFttHE47ezvs=.b7d09ab0-2b04-49b1-b02f-8c1a2e002e9d@github.com>

On Fri, 28 Apr 2023 08:00:36 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

I did an initial pass through the code. Added some small comments, mostly for future consideration, and one slightly bigger one around testing case where on-demand compilation fails.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 146:

> 144: 
> 145:     byte[] compileJavaFileByName(String name) throws Fault {
> 146:         var firstDollarSign = name.indexOf('$'); // [package . ] name [ $ enclosed ]

Nit - in principle, `$` is a valid identifier character:

jshell> Character.isJavaIdentifierStart('$')
$1 ==> true


So, in principle, the user's code may have classes with `$` in their names. OTOH, this seems like a very rare case given the context.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryFileManager.java line 52:

> 50:  * or deletion without notice.</b></p>
> 51:  */
> 52: final class MemoryFileManager extends ForwardingJavaFileManager<JavaFileManager> {

Just FWIW, I note this class does not support reading from the classfiles, so everything will be load from the source files during compilation.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java line 104:

> 102:                   .filter(string -> !string.isEmpty())
> 103:                   .map(string -> string.replace('/', '.'))
> 104:                   .map(string -> string.replace('\\', '.'))

Nit: I'd be a bit careful with the `` -> `.` replacement. `` is a valid file name character on UNIX-like system. Better use `File.separatorChar` or `sourceRootPath.getFileSystem().getSeparator()`. Although the practical impact is probably very low.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/SourceLauncher.java line 77:

> 75:         try {
> 76:             new SourceLauncher(System.err)
> 77:                     .checkSecurityManager()

Nit, fwiw: the SecurityManager check is not completely safe (as the user's program could install SM while providing -Djava.security.manager=allow), and then further compilation may be invoked, failing on SM. OTOH, given the state of SM, I don't think this needs changes.

test/langtools/tools/javac/launcher/Run.java line 49:

> 47:         PrintStream prev = System.out;
> 48:         ByteArrayOutputStream baos = new ByteArrayOutputStream();
> 49:         try (PrintStream out = new PrintStream(baos, true)) {

So, I am looking at this, and I am not sure how it can work and test what is needed. If the compilation fails during on-demand class loading, we stop using `System.exit`, and it seems to me this code cannot handle that, and so that there's probably no test testing that scenario?

I mean:


---Test.java
public class Test {
    public static void main(String... args) throws Throwable {
        Class.forName("Extra");
    }
}
----Extra.java
public class Broken
---

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

PR Review: https://git.openjdk.org/jdk/pull/13712#pullrequestreview-1679935689
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1360634635
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1360635959
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1360643655
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1360647244
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1360671662

From jlaskey at openjdk.org  Mon Oct 16 13:50:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 13:50:58 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second Preview)
Message-ID: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>

Update String Templates for a second preview. With the addition of

- Expression type and throws are determined from the `process` method of the processor type and not the processor type.

- Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .

- Raw (generic) process types are no longer an error.

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

Commit messages:
 - Accept qualified STR and RAW
 - String Templates (second preview)

Changes: https://git.openjdk.org/jdk/pull/16202/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315457
  Stats: 91 lines in 29 files changed: 29 ins; 30 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

PR: https://git.openjdk.org/jdk/pull/16202

From alanb at openjdk.org  Mon Oct 16 14:30:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 14:30:15 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview)
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>

On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:

> 134:      * @param value       value to mix in
> 135:      * @return            new length and coder
> 136:      * @since 22

The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360750529

From jlaskey at openjdk.org  Mon Oct 16 14:35:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 14:35:37 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview)
In-Reply-To: <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
Message-ID: <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>

On Mon, 16 Oct 2023 14:27:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:
> 
>> 134:      * @param value       value to mix in
>> 135:      * @return            new length and coder
>> 136:      * @since 22
> 
> The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

Wasn't sure about that. Thx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360757078

From asotona at openjdk.org  Mon Oct 16 16:18:38 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 16 Oct 2023 16:18:38 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v21]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <rsnTJXADAzGBSf5iry9CporhX3aJYoJog-37eFygWC0=.93b28aae-3387-45fd-aa61-59ab49efb8f8@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 352 commits:

 - removed trailing space
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - package info javadoc improvements
 - removed obsolete exports from BuildMicrobenchmark.gmk
 - Merge branch 'master' into JDK-8308753-preview
 - added @sealedGraph tags
 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test
 - removed AttributeMapper::validSince
 - fixed DirectCodeBuilder
 - ... and 342 more: https://git.openjdk.org/jdk/compare/eb7d972d...3b36c12c

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=20
  Stats: 32095 lines in 764 files changed: 14595 ins; 14023 del; 3477 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From jlaskey at openjdk.org  Mon Oct 16 16:20:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:20:12 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Revert source
 - Revert @since 22

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/b95c799e..f077ef6f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=00-01

  Stats: 26 lines in 19 files changed: 0 ins; 0 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

PR: https://git.openjdk.org/jdk/pull/16202

From jlahoda at openjdk.org  Mon Oct 16 16:20:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 16 Oct 2023 16:20:24 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
Message-ID: <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>

On Mon, 16 Oct 2023 15:23:25 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert source
>  - Revert @since 22

javac changes look reasonable to me. Added some mostly minor comments.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:

> 1689:         }
> 1690: 
> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {

This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 257:

> 255: 
> 256:         boolean isNamedProcessor(Name name) {
> 257:             Symbol sym = switch (processor) {

Maybe `TreeInfo.symbol(processor)` here?

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

PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1680264976
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360841404
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360830232

From vicente.romero at oracle.com  Mon Oct 16 16:46:11 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Mon, 16 Oct 2023 11:46:11 -0500
Subject: Regression: accessing a private method through a type variable
In-Reply-To: <c1fbee53-765a-441e-92b3-d39b5709cb06@oracle.com>
References: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>
 <c1fbee53-765a-441e-92b3-d39b5709cb06@oracle.com>
Message-ID: <a4a85d7f-e8df-4f3b-8a3e-b9f0bbe714d3@oracle.com>

Thanks for the report, we have created [1]. I'm taking a look at it,

Vicente

[1] https://bugs.openjdk.org/browse/JDK-8318160

On 10/16/23 07:15, Maurizio Cimadamore wrote:
>
> I recall fixing this a long time ago:
>
>
> https://bugs.openjdk.org/browse/JDK-6711619
>
>
> Now, the test case mentioned in that bug is still correctly rejected 
> by javac. Furhermore, a similar test:
>
>
> ```
> class X<E extends X<E>> {
> ???????????? private static int m() { return 1; }
> ???????????? int f() {
> ???????????????????? return E.m();
> ???????????? }
> ??? }
> ```
>
>
> Also fails to compile with 21/22.
>
>
> ```
> Test.java:5: error: m() has private access in X
> ???????????????????? return E.m();
> ???????????????????????????? ^
> 1 error
>
> ```
>
>
> Trying to manipulate Remi's example, it seems the regression only has 
> to do with method refreences whose receiver is a type variable.
>
>
> Here's a minimal reproducer:
>
>
> ```
> import java.util.function.*;
>
> class Test {
> ? private String asString() {
> ??? return "bar";
> ? }
>
> ? static <T extends Test> Function<T, String> foo() {
> ??? return T::asString;
> ? }
> }
> ```
>
> I filed a bug:
>
>
> https://bugs.openjdk.org/browse/JDK-6711619
>
>
> Thanks
> Maurizio
>
>
> On 16/10/2023 10:40, Sundararajan Athijegannathan wrote:
>> fwiw, this compile from at least JDK 11 onwards:
>>
>> import java.util.*;
>> import java.util.stream.*;
>>
>> public class TDotToString {
>> ? class Bar {
>> ? ? private String asString() {
>> ? ? ? return "bar";
>> ? ? }
>> ? }
>>
>> ? static <T extends Bar> String foo(List<T> list) {
>> ? ? return list.stream().map(T::asString).collect(Collectors.joining());
>> ? }
>> }
>>
>> javac from 1.8.0 does issue error as mentioned by Remi.
>>
>>
>> -Sundar
>> ------------------------------------------------------------------------
>> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of 
>> Remi Forax <forax at univ-mlv.fr>
>> *Sent:* 16 October 2023 13:57
>> *To:* compiler-dev <compiler-dev at openjdk.org>
>> *Subject:* Regression: accessing a private method through a type 
>> variable
>> Hello,
>> There is a regression in recent versions of javac.
>> javac 21 allows to access a private method through a type variable, 
>> here T::asString.
>>
>> public class TDotToString {
>> ? class Bar() {
>> ??? private String asString() {
>> ????? return "bar";
>> ??? }
>> ? }
>>
>> ? static <T extends Bar> String foo(List<T> list) {
>> ??? return list.stream().map(T::asString).collect(Collectors.joining());
>> ? }
>> }
>>
>> Both IntelliJ and Eclipse emit an error in this case.
>>
>> And javac 8 emits
>> ? TDotToString.java:12: error: invalid method reference
>> ??? return list.stream().map(T::asString).collect(Collectors.joining());
>> ???????????????????????????? ^
>> ? cannot find symbol
>> ??? symbol:?? method asString()
>> ??? location: bound of type variable T
>> ? where T is a type-variable:
>> ??? T extends TDotToString.Bar declared in method <T>foo(List<T>)
>> 1 error
>>
>> regards,
>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231016/09009b7b/attachment-0001.htm>

From jlaskey at openjdk.org  Mon Oct 16 16:54:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:54:13 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
 <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>
Message-ID: <zdgstS8vpSrxnnWMelorZ6DEwBN9tCp_kBF-u3ymbtk=.c68dc6d2-72b3-4226-94bb-26fcfa3cc0f1@github.com>

On Mon, 16 Oct 2023 15:17:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert source
>>  - Revert @since 22
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:
> 
>> 1689:         }
>> 1690: 
>> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {
> 
> This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.

I thought of the TreeInfo and Resolve idea but the number of arguments required made it messy. Hanging off of JCStringTemplate seemed like clutter to me.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 257:
> 
>> 255: 
>> 256:         boolean isNamedProcessor(Name name) {
>> 257:             Symbol sym = switch (processor) {
> 
> Maybe `TreeInfo.symbol(processor)` here?

Only want to allow JCIdent and and JCFieldAcesss. Other expressions can't produce the STR/RAW symbols, but ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360965274
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360962420

From xqoasis at openjdk.org  Mon Oct 16 17:17:35 2023
From: xqoasis at openjdk.org (Qing Xiao)
Date: Mon, 16 Oct 2023 17:17:35 GMT
Subject: Integrated: 8313613: Use JUnit in langtools/lib tests
In-Reply-To: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
References: <GObPXJADdNlWGXrejI1tZq1d2sxmvlSedXLYMKy_kYw=.f6d9762f-fee7-49ff-84b8-ad39752b165e@github.com>
Message-ID: <vbteF0OwxhO688rkQAZ-nlqACpizDd5C9Tp6z8xvm98=.1698af6e-7e30-4bc6-bc63-bab0e3266d3f@github.com>

On Mon, 14 Aug 2023 23:57:08 GMT, Qing Xiao <xqoasis at openjdk.org> wrote:

> Use JUnit Jupiter API in langtools/lib tests instead of TestNG. They are under test/langtools/lib/combo/tools/javac/combo/.
> Modified tests that extend tools in CompilationTestCase and JavacTemplateTestBase to implement TestWatcher.

This pull request has now been integrated.

Changeset: 741ae06c
Author:    Qing Xiao <xqoasis at openjdk.org>
Committer: Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/741ae06c55de65dcdfe38e328022bd8dde4fa007
Stats:     553 lines in 17 files changed: 204 ins; 105 del; 244 mod

8313613: Use JUnit in langtools/lib tests

Reviewed-by: cstein, asotona

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

PR: https://git.openjdk.org/jdk/pull/15281

From abimpoudis at openjdk.org  Mon Oct 16 17:25:27 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 17:25:27 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v20]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <JIYw7RLEx0HYelRrw83xawIsvi6xrndEeWtleS2Jie8=.2e47062c-2546-4737-b429-297243056ac6@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Address review
   
   - Add comments
   - Rename exactness methods
   - Use convenience methods from TypeTag for checkUnconditionallyExactPrimitives in Types
   - Port isStrictSubRangeOf to Wrapper and use it for unconditionalExactnessCheck in SwitchBootstraps
 - Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
 - Merge branch 'master' into primitive-patterns
 - Update name of exactness methods class
 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
   Co-authored-by: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
 - Fix exhaustiveness check for primitive types
 - Add tests
 - Improve non integral check
 - ... and 16 more: https://git.openjdk.org/jdk/compare/f1f3e73c...2f03b1b9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/d06b2172..2f03b1b9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=18-19

  Stats: 12908 lines in 521 files changed: 8067 ins; 2451 del; 2390 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Mon Oct 16 17:25:29 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 17:25:29 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <MylmnZRl3s8NNVh6PFLrxlVD23Cp8WdpLC4JZT-kBk0=.2aaceba6-e060-4707-a9e5-de921a5505df@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
 <MylmnZRl3s8NNVh6PFLrxlVD23Cp8WdpLC4JZT-kBk0=.2aaceba6-e060-4707-a9e5-de921a5505df@github.com>
Message-ID: <2hItDawsZ_qmMOTOQeLP81XQu1O0A3yyTGG_5xKACXA=.b3a4642d-7ca3-4675-8dc6-05d749bb2e73@github.com>

On Fri, 13 Oct 2023 09:33:28 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
>
> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 51:
> 
>> 49:      *
>> 50:      * */
>> 51:     public static boolean intToByteExact(int n)      {return n == (int)(byte)n;}
> 
> These ones seem more _conversions_ than _tests_.
> To me, `intToByteExact(int)` looks more like a request to convert an `int` to a `byte`, rather than a check to see whether the argument lies in the `byte` range.
> Pure methods returning `boolean` are often named like `isIntToByteExact(int)` or the like (`is*()`, `has*()`, etc.)
> 
> I know: choosing good, speaking, and evocative names is one of the hardest problem in computer science.

Good recommendation. Names updated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361013093

From abimpoudis at openjdk.org  Mon Oct 16 17:25:34 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 17:25:34 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v19]
In-Reply-To: <drb8XEdroVzBtUovSI2auUOTKRI89354Af9hQKdFXXg=.89001e48-fe4f-4580-92ef-814c34d66269@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <OgUPq9rdOqk8v2RLfYEK89qToiPd49sG0a8K9e4rCRU=.88f06fd2-0326-4e49-a60b-bfbf63a7edcc@github.com>
 <drb8XEdroVzBtUovSI2auUOTKRI89354Af9hQKdFXXg=.89001e48-fe4f-4580-92ef-814c34d66269@github.com>
Message-ID: <LrX5TYAMQ8OTWSxCrgI4qNG5EbYdUfuuik3m29fUdY8=.1c16024c-3868-4ed7-b5be-a4b9e81aac38@github.com>

On Thu, 12 Oct 2023 20:42:50 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
>
> src/java.base/share/classes/java/lang/runtime/SwitchBootstraps.java line 366:
> 
>> 364:             (selectorType.equals(int.class) && targetType.equals(Integer.class)))
>> 365:             return true;
>> 366:         else if (selectorType.equals(targetType) || (selectorType.equals(byte.class) && !targetType.equals(char.class)  ||
> 
> this code reminds me of some tricks we did to simplify similar code in the past, see `com.sun.tools.javac.code.TypeTag` and related:  `com.sun.tools.javac.code.TypeTag.NumericClasses` and method `com.sun.tools.javac.code.TypeTag::isSubRangeOf` and how it is used to determine if a numerical type is subtype of another numerical type. These tricks could be reused here, but up to you. I could also be done in a future refactoring.

Thanks for the recommendation. I used them and ported the subrange functionality to Wrappers (added two extra parameters for the enum variants).

> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 5055:
> 
>> 5053:         return (source.isPrimitive() && target.isPrimitive()) &&
>> 5054:                 ((source.hasTag(BYTE) && !target.hasTag(CHAR) ||
>> 5055:                         (source.hasTag(SHORT) && (target.hasTag(INT) || target.hasTag(LONG) || target.hasTag(FLOAT) || target.hasTag(DOUBLE)))||
> 
> this code can also be simplified as suggested for similar code in SwitchBootstraps, actually here you have access to the infra already in TypeTag and can leverage it.

Done.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Lower.java line 2910:
> 
>> 2908:     }
>> 2909: 
>> 2910:     public void visitTypeTest(JCInstanceOf tree) {
> 
> would it make sense to document how the generated code should look like?

Done!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361010084
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361013492
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1361010752

From abimpoudis at openjdk.org  Mon Oct 16 18:02:22 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 18:02:22 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v5]
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <nciAworJ1J98O0lcE8v1C3-E2uZ4noGW47bN2ViISeQ=.38260058-9a0d-4c85-9e8a-6feedf2dae09@github.com>

> This PR finalizes the feature of unnamed variables and patterns.

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

 - Merge branch 'master' into unnamed
 - Add test with multi-catch
 - Merge branch 'master' into unnamed
 - Address review by @mcimadamore
 - Address review by @lahodaj
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/ccbfbd4f..13a4b6f8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=03-04

  Stats: 12707 lines in 528 files changed: 7998 ins; 2437 del; 2272 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From abimpoudis at openjdk.org  Mon Oct 16 19:16:41 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 16 Oct 2023 19:16:41 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v21]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>

> This is the first draft of a patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Adjust javadoc on ExactConversionsSupport

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/2f03b1b9..ac0b6782

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=19-20

  Stats: 7 lines in 1 file changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From vromero at openjdk.org  Tue Oct 17 00:32:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 00:32:51 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver
Message-ID: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>

Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:


import java.util.function.*;

class Test {
    private String asString() {
        return "bar";
    }

    static <T extends Test> Function<T, String> foo() {
        return T::asString;
    }
}


this code should be rejected on the grounds that ::asString is a private method in class Test and no subclass of it should have access to this method. This regression was introduced in JDK9 so it could be that there is code depending on this bug.

TIA

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

Commit messages:
 - 8318160: javac does not reject private method reference with type-variable receiver

Changes: https://git.openjdk.org/jdk/pull/16210/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318160
  Stats: 30 lines in 4 files changed: 28 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16210/head:pull/16210

PR: https://git.openjdk.org/jdk/pull/16210

From vromero at openjdk.org  Tue Oct 17 00:32:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 00:32:52 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>

On Tue, 17 Oct 2023 00:19:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class Test and no subclass of it should have access to this method. This regression was introduced in JDK9 so it could be that there is code depending on this bug.
> 
> TIA

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3555:

> 3553:         MethodReferenceLookupHelper(JCMemberReference referenceTree, Name name, Type site,
> 3554:                 List<Type> argtypes, List<Type> typeargtypes, MethodResolutionPhase maxPhase) {
> 3555:             super(referenceTree, name, types.skipTypeVars(site, true, true), argtypes, typeargtypes, maxPhase);

I believe the right thing here should be to skip captured type variables but not "non-captured" type variables

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1361382803

From vromero at openjdk.org  Tue Oct 17 03:28:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 03:28:51 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v2]
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <rfqAstQ0kh_hlPMqM9t90-NhCf1fxkMYL93E_4ZIaQQ=.c2207205-f812-449b-beb3-1f3b833c04d7@github.com>

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class Test and no subclass of it should have access to this method. This regression was introduced in JDK9 so it could be that there is code depending on this bug.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16210/files
  - new: https://git.openjdk.org/jdk/pull/16210/files/40276e92..d540b00a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/16210

From vromero at openjdk.org  Tue Oct 17 03:55:44 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 03:55:44 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v3]
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <nZp7R6dI6n5mRRXfZ0gWK9O7JllKfchsK5ntZk_9UPo=.294fb790-1538-490e-8c32-2a7d6f21acae@github.com>

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class Test and no subclass of it should have access to this method. This regression was introduced in JDK9 so it could be that there is code depending on this bug.
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  additional test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16210/files
  - new: https://git.openjdk.org/jdk/pull/16210/files/d540b00a..0ddafd4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=01-02

  Stats: 14 lines in 2 files changed: 10 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16210/head:pull/16210

PR: https://git.openjdk.org/jdk/pull/16210

From mcimadamore at openjdk.org  Tue Oct 17 12:20:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 17 Oct 2023 12:20:55 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v3]
In-Reply-To: <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
Message-ID: <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>

On Tue, 17 Oct 2023 00:26:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3555:
> 
>> 3553:         MethodReferenceLookupHelper(JCMemberReference referenceTree, Name name, Type site,
>> 3554:                 List<Type> argtypes, List<Type> typeargtypes, MethodResolutionPhase maxPhase) {
>> 3555:             super(referenceTree, name, types.skipTypeVars(site, true, true), argtypes, typeargtypes, maxPhase);
> 
> I believe the right thing here should be to skip captured type variables but not "non-captured" type variables

Not sure... if you have:

class Foo<X> {
   X get()
}

And then:


static Function<?, String> m2(Foo<? extends Test> foo) {
        return foo.get()::asString2;
    }
 ```
 
 Don't you end up with a similar issue?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1362021487

From rgiulietti at openjdk.org  Tue Oct 17 12:39:13 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 17 Oct 2023 12:39:13 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v21]
In-Reply-To: <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
Message-ID: <nuk6fDtyDeOmlNbKl7t66N60yR0lFWAow442rjjxsrk=.7833756d-9a18-49b6-93ce-3552205ca336@github.com>

On Mon, 16 Oct 2023 19:16:41 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust javadoc on ExactConversionsSupport

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 40:

> 38:  *
> 39:  * @implNote Methods that describe a conversion check among unconditionally exact types
> 40:  * (they would return true) are ommited. Similarly, methods that describe a conversion check

Suggestion:

 * (they would return true) are omitted. Similarly, methods that describe a conversion check

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 54:

> 52:      * Exactness method from int to byte
> 53:      * @param n value
> 54:      * @return  true if the passed value can be converted exactly to the target type

Suggestion:

     * @return  true if and only if the passed value can be converted exactly to the target type

Without the "only if", the method could simply always return `true` while meeting the `@return` "contract" ;-)

Alternatively
Suggestion:

     * @return  whether or not the passed value can be converted exactly to the target type


Similarly for all other methods.

src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 80:

> 78:      * specification of the {@linkplain Double} class.
> 79:      */
> 80:     public static boolean isIntToFloatExact(int n) { return n == (int)(float)n && n != Integer.MAX_VALUE; }

Suggestion:

    public static boolean isIntToFloatExact(int n) {
        return n == (int)(float)n && n != Integer.MAX_VALUE;
    }

Nit: what about formatting this on 3 lines?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362005727
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362008344
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362043660

From abimpoudis at openjdk.org  Tue Oct 17 12:55:11 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 12:55:11 GMT
Subject: Integrated: 8314578: Non-verifiable code is emitted when two guards
 declare pattern variables in colon-switch
In-Reply-To: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
References: <oqs2tqPQKyYB_nRHNx5ZL9WWpTlaGymVAi8NSGU_Kxc=.1b70daac-ea2f-456c-9b92-9a71d74f572c@github.com>
Message-ID: <wVvGN28dn2Fhxq_psL5sjyzDHgBx0-WyetQ2tWADJu0=.aa01fdd1-92ab-4bdc-a3c0-9bc41bd42ec7@github.com>

On Fri, 8 Sep 2023 09:32:50 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> In the following example while the case pattern does not introduce binding variable, the guard does. `hasBindings` has been updated accordingly to accept any trees and check them if they contain a `visitBindingPattern`. Not only `JCPattern`'s.
> 
> 
> static void test(Object o) {
>     switch (o) {
>       case R1() when o instanceof String s:
>       case R2() when o instanceof Integer i:
>         System.out.println("hello: " + i);
>         break;
>       default:
>         break;
>     }
>   }

This pull request has now been integrated.

Changeset: 15588e08
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15588e08ed455eac356aa923c35503beaecd5b6d
Stats:     52 lines in 3 files changed: 49 ins; 0 del; 3 mod

8314578: Non-verifiable code is emitted when two guards declare pattern variables in colon-switch

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/15630

From abimpoudis at openjdk.org  Tue Oct 17 13:02:03 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 13:02:03 GMT
Subject: Integrated: 8317300: javac erroneously allows "final" in front of a
 record pattern
In-Reply-To: <O2KHdJQLfVfTbOpkht3lOCmhE8QLuBCHTocmBZ4tVV4=.9bb2fd68-3700-4234-be04-3cb7f9a6dcf3@github.com>
References: <O2KHdJQLfVfTbOpkht3lOCmhE8QLuBCHTocmBZ4tVV4=.9bb2fd68-3700-4234-be04-3cb7f9a6dcf3@github.com>
Message-ID: <u7tJXa3sceja4jZg-gNYmL5PogXcJ6ZOIPGCkZKPIxo=.074f243c-5d77-4493-846d-99f095566d41@github.com>

On Sat, 30 Sep 2023 08:00:44 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> Introduces the relevant check for `final` in record patterns.

This pull request has now been integrated.

Changeset: 5ca1beb3
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ca1beb30e35cc91bf170960fb832de6438de1de
Stats:     30 lines in 3 files changed: 30 ins; 0 del; 0 mod

8317300: javac erroneously allows "final" in front of a record pattern

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/15997

From vromero at openjdk.org  Tue Oct 17 13:35:30 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 13:35:30 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v4]
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <klMHoGPTIQ7buJ9U4GiEex5gWfZvnEzsvHY8L0817bA=.c551a2bf-7a88-49cb-852f-682571aa6be7@github.com>

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class `Test` and thus not a member of type variable `T`
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  fixing bug in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16210/files
  - new: https://git.openjdk.org/jdk/pull/16210/files/0ddafd4d..be5760d5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=02-03

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

PR: https://git.openjdk.org/jdk/pull/16210

From vromero at openjdk.org  Tue Oct 17 14:09:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 14:09:08 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v5]
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <OgrPN3zA1E7RzDCRjXRhXO5u4aIKfnDlZh6K-cV4y24=.e3d7abbb-a4d7-4237-ac0f-4c911443bda2@github.com>

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class `Test` and thus not a member of type variable `T`
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  forgot to add parameter to method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16210/files
  - new: https://git.openjdk.org/jdk/pull/16210/files/be5760d5..73377326

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=03-04

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

PR: https://git.openjdk.org/jdk/pull/16210

From vromero at openjdk.org  Tue Oct 17 14:09:10 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 14:09:10 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v5]
In-Reply-To: <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
 <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>
Message-ID: <0SLFMdfVUUOcbgrlSsgZ9hWrLPR1ZyseV5ikoxklQ_Y=.f9860d47-4fff-43a1-8506-ef5e435623b8@github.com>

On Tue, 17 Oct 2023 12:18:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Resolve.java line 3555:
>> 
>>> 3553:         MethodReferenceLookupHelper(JCMemberReference referenceTree, Name name, Type site,
>>> 3554:                 List<Type> argtypes, List<Type> typeargtypes, MethodResolutionPhase maxPhase) {
>>> 3555:             super(referenceTree, name, types.skipTypeVars(site, true, true), argtypes, typeargtypes, maxPhase);
>> 
>> I believe the right thing here should be to skip captured type variables but not "non-captured" type variables
>
> Not sure... if you have:
> 
> class Foo<X> {
>    X get()
> }
> 
> And then:
> 
> 
> static Function<?, String> m2(Foo<? extends Test> foo) {
>         return foo.get()::asString2;
>     }
>  ```
>  
>  Don't you end up with a similar issue?

right nice example thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1362093082

From abimpoudis at openjdk.org  Tue Oct 17 14:44:38 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 14:44:38 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v22]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <LboRxKdK3cnvv6LdsGdBIMCxgsuv64KA2A0suiVHp-w=.63c21c95-716b-48ba-bc73-6884a923e766@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Improve javadoc of ExactConversionsSupport
  
  Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/ac0b6782..b9237148

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=20-21

  Stats: 25 lines in 1 file changed: 1 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From abimpoudis at openjdk.org  Tue Oct 17 14:44:48 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 14:44:48 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v21]
In-Reply-To: <nuk6fDtyDeOmlNbKl7t66N60yR0lFWAow442rjjxsrk=.7833756d-9a18-49b6-93ce-3552205ca336@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
 <nuk6fDtyDeOmlNbKl7t66N60yR0lFWAow442rjjxsrk=.7833756d-9a18-49b6-93ce-3552205ca336@github.com>
Message-ID: <TQJjHPzkUjgmhaRza3omHzpgDsE2GE3xlhmbImEpB04=.8c30d971-4033-4db5-b1af-1ce91894c84a@github.com>

On Tue, 17 Oct 2023 12:06:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust javadoc on ExactConversionsSupport
>
> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 54:
> 
>> 52:      * Exactness method from int to byte
>> 53:      * @param n value
>> 54:      * @return  true if the passed value can be converted exactly to the target type
> 
> Suggestion:
> 
>      * @return  true if and only if the passed value can be converted exactly to the target type
> 
> Without the "only if", the method could simply always return `true` while meeting the `@return` "contract" ;-)
> 
> Alternatively
> Suggestion:
> 
>      * @return  whether or not the passed value can be converted exactly to the target type
> 
> 
> Similarly for all other methods.

Good point! Thx

> src/java.base/share/classes/java/lang/runtime/ExactConversionsSupport.java line 80:
> 
>> 78:      * specification of the {@linkplain Double} class.
>> 79:      */
>> 80:     public static boolean isIntToFloatExact(int n) { return n == (int)(float)n && n != Integer.MAX_VALUE; }
> 
> Suggestion:
> 
>     public static boolean isIntToFloatExact(int n) {
>         return n == (int)(float)n && n != Integer.MAX_VALUE;
>     }
> 
> Nit: what about formatting this on 3 lines?

Looks better indeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362247167
PR Review Comment: https://git.openjdk.org/jdk/pull/15638#discussion_r1362247460

From jlahoda at openjdk.org  Tue Oct 17 15:20:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 17 Oct 2023 15:20:25 GMT
Subject: RFR: 8316470: Incorrect error location for "invalid permits clause"
 depending on file order
Message-ID: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>

Consider code like (in two different files, but accessible through source path):

class Main extends C {}


sealed class C {} //does not permit Main


and a javac process that will start attribution with `Main`. As part of `Main` attribution, its superclasses will be attributed, hence `C` will be attributed. And there will be a sealing error reported for `C` (missing permitted). But, the source in the logger will still be set to `Main`, and hence the report will be reported at a weird place in `Main`, not in `C`.

The proposed solution is simple: move the code to set the source to logger (and related code) before the sealed checks. The diff looks scary, but it is movement of several lines up, and whitespace changes.

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

Commit messages:
 - 8316470: Incorrect error location for "invalid permits clause" depending on file order

Changes: https://git.openjdk.org/jdk/pull/16221/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16221&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316470
  Stats: 279 lines in 2 files changed: 178 ins; 31 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/16221.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16221/head:pull/16221

PR: https://git.openjdk.org/jdk/pull/16221

From cstein at openjdk.org  Tue Oct 17 15:28:04 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Oct 2023 15:28:04 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v2]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <O2cNfj9OaPpaUX8mTMNBAqST-FVN2VmV3WE50HpC0i4=.21cefb32-ede7-4798-b465-7cb468a2d45a@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

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

  Fix support for adding user-supplied modules on the module-path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/f589a7c1..093ab1ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=00-01

  Stats: 79 lines in 3 files changed: 58 ins; 4 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13712/head:pull/13712

PR: https://git.openjdk.org/jdk/pull/13712

From cstein at openjdk.org  Tue Oct 17 15:28:07 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Oct 2023 15:28:07 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v2]
In-Reply-To: <s-rTg6Wxi-nfqWz_RpGhBJWXlK4hcIQvFttHE47ezvs=.b7d09ab0-2b04-49b1-b02f-8c1a2e002e9d@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <s-rTg6Wxi-nfqWz_RpGhBJWXlK4hcIQvFttHE47ezvs=.b7d09ab0-2b04-49b1-b02f-8c1a2e002e9d@github.com>
Message-ID: <_KIjcw9sp09uXT2yBWmgMeOy11qFod5I1eZ2C6hNdQg=.ce523ce1-f963-41f6-b7bb-44f80a097013@github.com>

On Mon, 16 Oct 2023 13:09:37 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix support for adding user-supplied modules on the module-path
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java line 104:
> 
>> 102:                   .filter(string -> !string.isEmpty())
>> 103:                   .map(string -> string.replace('/', '.'))
>> 104:                   .map(string -> string.replace('\\', '.'))
> 
> Nit: I'd be a bit careful with the `` -> `.` replacement. `` is a valid file name character on UNIX-like system. Better use `File.separatorChar` or `sourceRootPath.getFileSystem().getSeparator()`. Although the practical impact is probably very low.

Addressed this in https://github.com/openjdk/jdk/pull/13712/commits/093ab1cef7383323deb74bffa511b81109ca4dd6

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1362314991

From cstein at openjdk.org  Tue Oct 17 15:32:17 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 17 Oct 2023 15:32:17 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v2]
In-Reply-To: <s-rTg6Wxi-nfqWz_RpGhBJWXlK4hcIQvFttHE47ezvs=.b7d09ab0-2b04-49b1-b02f-8c1a2e002e9d@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <s-rTg6Wxi-nfqWz_RpGhBJWXlK4hcIQvFttHE47ezvs=.b7d09ab0-2b04-49b1-b02f-8c1a2e002e9d@github.com>
Message-ID: <lt9TkBTdrvyRx9eHokwhyJCvEHXP9kGgh-nNDJSVGx8=.9d58b809-fbb1-4866-9501-566cd4084bd4@github.com>

On Mon, 16 Oct 2023 13:30:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix support for adding user-supplied modules on the module-path
>
> test/langtools/tools/javac/launcher/Run.java line 49:
> 
>> 47:         PrintStream prev = System.out;
>> 48:         ByteArrayOutputStream baos = new ByteArrayOutputStream();
>> 49:         try (PrintStream out = new PrintStream(baos, true)) {
> 
> So, I am looking at this, and I am not sure how it can work and test what is needed. If the compilation fails during on-demand class loading, we stop using `System.exit`, and it seems to me this code cannot handle that, and so that there's probably no test testing that scenario?
> 
> I mean:
> 
> 
> ---Test.java
> public class Test {
>     public static void main(String... args) throws Throwable {
>         Class.forName("Extra");
>     }
> }
> ----Extra.java
> public class Broken
> ---

There is a test in `MultiFileSourceLauncherTests` that checks this with a broken second file: `testSecondUnitWithSyntaxError`, including an assertion for the syntax error being emitted.

And I recall to have seen the error code `2` in a manual test - but there's no automated test for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1362327231

From jlaskey at openjdk.org  Tue Oct 17 16:03:25 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Oct 2023 16:03:25 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v3]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Cache process method type in JCStringTemplate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/f077ef6f..ae136779

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=01-02

  Stats: 13 lines in 3 files changed: 2 ins; 10 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

PR: https://git.openjdk.org/jdk/pull/16202

From jlaskey at openjdk.org  Tue Oct 17 16:03:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Oct 2023 16:03:28 GMT
Subject: RFR: JDK-8315457 Implementation of String Templates (Second
 Preview) [v2]
In-Reply-To: <zdgstS8vpSrxnnWMelorZ6DEwBN9tCp_kBF-u3ymbtk=.c68dc6d2-72b3-4226-94bb-26fcfa3cc0f1@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
 <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>
 <zdgstS8vpSrxnnWMelorZ6DEwBN9tCp_kBF-u3ymbtk=.c68dc6d2-72b3-4226-94bb-26fcfa3cc0f1@github.com>
Message-ID: <iSGDWs1Cgbn-orD9wgZLzDRddsoDymA_4DOz7AL8-Gw=.21ad6946-b19b-4bea-96b3-044ee1c1a121@github.com>

On Mon, 16 Oct 2023 16:51:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:
>> 
>>> 1689:         }
>>> 1690: 
>>> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {
>> 
>> This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.
>
> I thought of the TreeInfo and Resolve idea but the number of arguments required made it messy. Hanging off of JCStringTemplate seemed like clutter to me. If I could use the method symbol in TransLiterals it might make sense. I'll ponder on it.

Added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1362377976

From vromero at openjdk.org  Tue Oct 17 17:51:08 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 17:51:08 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v22]
In-Reply-To: <LboRxKdK3cnvv6LdsGdBIMCxgsuv64KA2A0suiVHp-w=.63c21c95-716b-48ba-bc73-6884a923e766@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <LboRxKdK3cnvv6LdsGdBIMCxgsuv64KA2A0suiVHp-w=.63c21c95-716b-48ba-bc73-6884a923e766@github.com>
Message-ID: <YsAbuh_kjQklou3yHh2oCo1r-fcEwNrFAq5mj_AxmCQ=.2eca81d6-f1a9-4f4b-99cb-5752079212ea@github.com>

On Tue, 17 Oct 2023 14:44:38 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
>> 
>> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc of ExactConversionsSupport
>   
>   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>

thanks! lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15638#pullrequestreview-1683007779

From abimpoudis at openjdk.org  Tue Oct 17 23:12:19 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 23:12:19 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v6]
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <XuRVMWJRQst3rwCjgUwBKJXqCk5YJvO5BaSfmyB6CU8=.b3fd63f4-1314-4bd4-a417-f5ff12e11777@github.com>

> This PR finalizes the feature of unnamed variables and patterns.

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

 - Merge branch 'master' into unnamed
 - Merge branch 'master' into unnamed
 - Add test with multi-catch
 - Merge branch 'master' into unnamed
 - Address review by @mcimadamore
 - Address review by @lahodaj
 - 8315532: Compiler Implementation for Unnamed Variables and Patterns

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/13a4b6f8..067e358c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=04-05

  Stats: 2480 lines in 135 files changed: 1806 ins; 306 del; 368 mod
  Patch: https://git.openjdk.org/jdk/pull/15649.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15649/head:pull/15649

PR: https://git.openjdk.org/jdk/pull/15649

From abimpoudis at openjdk.org  Tue Oct 17 23:12:46 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 23:12:46 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v23]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <32O0ulOuwl-JFnnLg0056h_56Ovbc8B3tKqBlg-MISM=.98ed6a51-53e4-4f8e-927a-6b61a1ed9daf@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

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

 - Merge branch 'master' into primitive-patterns
 - Improve javadoc of ExactConversionsSupport
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Adjust javadoc on ExactConversionsSupport
 - Merge branch 'master' into primitive-patterns
 - Address review
   
   - Add comments
   - Rename exactness methods
   - Use convenience methods from TypeTag for checkUnconditionallyExactPrimitives in Types
   - Port isStrictSubRangeOf to Wrapper and use it for unconditionalExactnessCheck in SwitchBootstraps
 - Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
 - Merge branch 'master' into primitive-patterns
 - Update name of exactness methods class
 - Merge branch 'master' into primitive-patterns
 - Adjust tests
   
   Co-authored-by: Jan Lahoda <jan.lahoda at oracle.com>
   Co-authored-by: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
 - ... and 19 more: https://git.openjdk.org/jdk/compare/61a05796...4acb66e0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/b9237148..4acb66e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=21-22

  Stats: 3033 lines in 152 files changed: 2010 ins; 411 del; 612 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From vromero at openjdk.org  Tue Oct 17 23:15:12 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 23:15:12 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v6]
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <N2aPCRfRxLgILQR-BQBdFbnWndqzsgLSpADaYyeYkPo=.65c3a103-0b6e-4185-af47-5c0f548bfffb@github.com>

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class `Test` and thus not a member of type variable `T`
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  alternative implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16210/files
  - new: https://git.openjdk.org/jdk/pull/16210/files/73377326..43f5fb74

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=04-05

  Stats: 37 lines in 4 files changed: 23 ins; 7 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/16210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16210/head:pull/16210

PR: https://git.openjdk.org/jdk/pull/16210

From vromero at openjdk.org  Tue Oct 17 23:24:45 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 17 Oct 2023 23:24:45 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v6]
In-Reply-To: <0SLFMdfVUUOcbgrlSsgZ9hWrLPR1ZyseV5ikoxklQ_Y=.f9860d47-4fff-43a1-8506-ef5e435623b8@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
 <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>
 <0SLFMdfVUUOcbgrlSsgZ9hWrLPR1ZyseV5ikoxklQ_Y=.f9860d47-4fff-43a1-8506-ef5e435623b8@github.com>
Message-ID: <X5hmk-2pRbzqyOWgS3d8aG6f2oAwUTHGjAYxLLhpRKQ=.a8875502-5236-4ad7-aa18-a4f770ec8747@github.com>

On Tue, 17 Oct 2023 13:13:29 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Not sure... if you have:
>> 
>> class Foo<X> {
>>    X get()
>> }
>> 
>> And then:
>> 
>> 
>> static Function<?, String> m2(Foo<? extends Test> foo) {
>>         return foo.get()::asString2;
>>     }
>>  ```
>>  
>>  Don't you end up with a similar issue?
>
> right nice example thanks

I made several experiments and decided for the approach in the last commit pushed. We will need an additional field in class `MethodResolutionContext` basically pointing to the current `LookupHelper` which can now decide if a symbol is inherited at a given site or not. Semantically there are not changes for any other method the only semantic change will be when we are looking for the method in a method reference.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1362919699

From abimpoudis at openjdk.org  Wed Oct 18 10:18:16 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 10:18:16 GMT
Subject: RFR: 8316470: Incorrect error location for
 "invalid permits clause" depending on file order
In-Reply-To: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>
References: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>
Message-ID: <MTN8kgYXjl9--Q5xGEXoa6jQp0aqCe-rSp_jQmhCiLo=.3d3c86a9-e936-4fa8-9791-6f05449e1d6d@github.com>

On Tue, 17 Oct 2023 15:10:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like (in two different files, but accessible through source path):
> 
> class Main extends C {}
> 
> 
> sealed class C {} //does not permit Main
> 
> 
> and a javac process that will start attribution with `Main`. As part of `Main` attribution, its superclasses will be attributed, hence `C` will be attributed. And there will be a sealing error reported for `C` (missing permitted). But, the source in the logger will still be set to `Main`, and hence the report will be reported at a weird place in `Main`, not in `C`.
> 
> The proposed solution is simple: move the code to set the source to logger (and related code) before the sealed checks. The diff looks scary, but it is movement of several lines up, and whitespace changes.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5422:

> 5420:             ResultInfo prevReturnRes = env.info.returnResult;
> 5421: 
> 5422:             try {

Previously this `try` block didn't include this code. Is, the new position of `try`, intentional?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16221#discussion_r1363617182

From abimpoudis at openjdk.org  Wed Oct 18 10:29:32 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 10:29:32 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables and
 Patterns [v7]
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <8a80EqSdoXu1bOUwloeZHStv8K0gnCScllreKIa4aYQ=.f4e97671-1d40-4eb8-b4d8-9b0c8d98845e@github.com>

> This PR finalizes the feature of unnamed variables and patterns.

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Remove preview lines from a new .out file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15649/files
  - new: https://git.openjdk.org/jdk/pull/15649/files/067e358c..bd43790b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15649&range=05-06

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

PR: https://git.openjdk.org/jdk/pull/15649

From mcimadamore at openjdk.org  Wed Oct 18 10:56:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 10:56:28 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v6]
In-Reply-To: <X5hmk-2pRbzqyOWgS3d8aG6f2oAwUTHGjAYxLLhpRKQ=.a8875502-5236-4ad7-aa18-a4f770ec8747@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
 <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>
 <0SLFMdfVUUOcbgrlSsgZ9hWrLPR1ZyseV5ikoxklQ_Y=.f9860d47-4fff-43a1-8506-ef5e435623b8@github.com>
 <X5hmk-2pRbzqyOWgS3d8aG6f2oAwUTHGjAYxLLhpRKQ=.a8875502-5236-4ad7-aa18-a4f770ec8747@github.com>
Message-ID: <rg6KvGcmrf7rVv-990h_4oK5ohySu4moLYM1DL83BuM=.dbbf98d7-287c-4cbe-aa33-7daa27b86656@github.com>

On Tue, 17 Oct 2023 23:21:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> right nice example thanks
>
> I made several experiments and decided for the approach in the last commit pushed. We will need an additional field in class `MethodResolutionContext` basically pointing to the current `LookupHelper` which can now decide if a symbol is inherited at a given site or not. Semantically there are not changes for any other method the only semantic change will be when we are looking for the method in a method reference.

I looked at the Resolve code some more, and also looked at the fix which likely caused this: 
https://bugs.openjdk.org/browse/JDK-8073842

So, `Resolve::findMethod` basically must NOT be called on a `site` Type that is a type variable. The original method resolution code enforces this in Attr::selectSym:

https://github.com/openjdk/jdk/blob/6fc35142315f1616fa35e415005c9483939c6920/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4575

Note that here:

1. If we see that the qualifier is a type variable, we recurse on the upper bound
2. If we find that we ended up accessing a symbol that was private, replace the symbol with an access error
3. call `accessBase` on the final symbol

I think a similar fix should be possible for method references. That is, as we do now, normalize the `site` using `skipTypeVars`, but also save the original `site` somewhere (as we already do). Note that the LookupHelper class has an `access` method, which is used to validate the result of the lookup (e.g. typically call `accessBase` on it). Effectively, this is a post-resolution step, pretty much like the one in `Attr`, so we can add whatever logic we want there (I think replicating the code in `Attr`  - see steps above - would be the best).

So, I don't think we need to add the new `isInherited` method - just overriding `access` to do the same thing we do in `Attr::selectSym` should be enough (I hope)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1363668229

From mcimadamore at openjdk.org  Wed Oct 18 11:02:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 11:02:55 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v6]
In-Reply-To: <rg6KvGcmrf7rVv-990h_4oK5ohySu4moLYM1DL83BuM=.dbbf98d7-287c-4cbe-aa33-7daa27b86656@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
 <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>
 <0SLFMdfVUUOcbgrlSsgZ9hWrLPR1ZyseV5ikoxklQ_Y=.f9860d47-4fff-43a1-8506-ef5e435623b8@github.com>
 <X5hmk-2pRbzqyOWgS3d8aG6f2oAwUTHGjAYxLLhpRKQ=.a8875502-5236-4ad7-aa18-a4f770ec8747@github.com>
 <rg6KvGcmrf7rVv-990h_4oK5ohySu4moLYM1DL83BuM=.dbbf98d7-287c-4cbe-aa33-7daa27b86656@github.com>
Message-ID: <VcB0YPP3mXref3mHIUW0zorKGIc-izTptFn7uyoo1IQ=.cb5f6a13-5184-4bab-ab45-c51f5d30860d@github.com>

On Wed, 18 Oct 2023 10:54:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I made several experiments and decided for the approach in the last commit pushed. We will need an additional field in class `MethodResolutionContext` basically pointing to the current `LookupHelper` which can now decide if a symbol is inherited at a given site or not. Semantically there are not changes for any other method the only semantic change will be when we are looking for the method in a method reference.
>
> I looked at the Resolve code some more, and also looked at the fix which likely caused this: 
> https://bugs.openjdk.org/browse/JDK-8073842
> 
> So, `Resolve::findMethod` basically must NOT be called on a `site` Type that is a type variable. The original method resolution code enforces this in Attr::selectSym:
> 
> https://github.com/openjdk/jdk/blob/6fc35142315f1616fa35e415005c9483939c6920/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4575
> 
> Note that here:
> 
> 1. If we see that the qualifier is a type variable, we recurse on the upper bound
> 2. If we find that we ended up accessing a symbol that was private, replace the symbol with an access error
> 3. call `accessBase` on the final symbol
> 
> I think a similar fix should be possible for method references. That is, as we do now, normalize the `site` using `skipTypeVars`, but also save the original `site` somewhere (as we already do). Note that the LookupHelper class has an `access` method, which is used to validate the result of the lookup (e.g. typically call `accessBase` on it). Effectively, this is a post-resolution step, pretty much like the one in `Attr`, so we can add whatever logic we want there (I think replicating the code in `Attr`  - see steps above - would be the best).
> 
> So, I don't think we need to add the new `isInherited` method - just overriding `access` to do the same thing we do in `Attr::selectSym` should be enough (I hope)

In fact... looking more - I see that `ReferenceLookupHelper` already overrides `access`. But this class doesn't have `originalSite` so you can't add the new access check here. So, `MethodReferenceLookupHelper` would have to override, add the new access check and call the super method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1363676172

From abimpoudis at openjdk.org  Wed Oct 18 13:55:28 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 13:55:28 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v24]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <8MeIwxrLkHfHK2L1Apr_86j9aA6M1vgt9tTE5UrX8gQ=.3cf317f0-dee5-4691-91e7-368ab7cee2f5@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix SwitchBootstraps for pattern matching over longs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/4acb66e0..248971be

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=22-23

  Stats: 27 lines in 2 files changed: 26 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From vromero at openjdk.org  Wed Oct 18 18:22:00 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 18 Oct 2023 18:22:00 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v7]
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <gZVQoFI2p-rNua_HLJ6jxl1m3S8RTW10Si0FILBYd1Q=.b1fb7a88-78da-4e89-b108-0f0cafa0c1b7@github.com>

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class `Test` and thus not a member of type variable `T`
> 
> TIA

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  another implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16210/files
  - new: https://git.openjdk.org/jdk/pull/16210/files/43f5fb74..4841c95c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16210&range=05-06

  Stats: 20 lines in 2 files changed: 5 ins; 7 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/16210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16210/head:pull/16210

PR: https://git.openjdk.org/jdk/pull/16210

From vromero at openjdk.org  Wed Oct 18 18:45:19 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 18 Oct 2023 18:45:19 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v7]
In-Reply-To: <VcB0YPP3mXref3mHIUW0zorKGIc-izTptFn7uyoo1IQ=.cb5f6a13-5184-4bab-ab45-c51f5d30860d@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <6ElroH5Rasps26bUBk6mHwNCbrPtam1KwnfUOXyDeKU=.c187ac3d-36f7-4ef4-9bfe-f7df98241a4a@github.com>
 <0K5WsIvU9SdUVLW5gH6pCGh438X64YN2HerAM-q8Frk=.dcfddb7e-c01c-4bc0-93b8-87859083a4f4@github.com>
 <0SLFMdfVUUOcbgrlSsgZ9hWrLPR1ZyseV5ikoxklQ_Y=.f9860d47-4fff-43a1-8506-ef5e435623b8@github.com>
 <X5hmk-2pRbzqyOWgS3d8aG6f2oAwUTHGjAYxLLhpRKQ=.a8875502-5236-4ad7-aa18-a4f770ec8747@github.com>
 <rg6KvGcmrf7rVv-990h_4oK5ohySu4moLYM1DL83BuM=.dbbf98d7-287c-4cbe-aa33-7daa27b86656@github.com>
 <VcB0YPP3mXref3mHIUW0zorKGIc-izTptFn7uyoo1IQ=.cb5f6a13-5184-4bab-ab45-c51f5d30860d@github.com>
Message-ID: <ESiLJ-k5b78qruNOFPOgxVKuNl3QDhWLYcmGSJa2peY=.77424e3b-6fe7-441a-a80e-e9b5f71cf052@github.com>

On Wed, 18 Oct 2023 11:00:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I looked at the Resolve code some more, and also looked at the fix which likely caused this: 
>> https://bugs.openjdk.org/browse/JDK-8073842
>> 
>> So, `Resolve::findMethod` basically must NOT be called on a `site` Type that is a type variable. The original method resolution code enforces this in Attr::selectSym:
>> 
>> https://github.com/openjdk/jdk/blob/6fc35142315f1616fa35e415005c9483939c6920/src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java#L4575
>> 
>> Note that here:
>> 
>> 1. If we see that the qualifier is a type variable, we recurse on the upper bound
>> 2. If we find that we ended up accessing a symbol that was private, replace the symbol with an access error
>> 3. call `accessBase` on the final symbol
>> 
>> I think a similar fix should be possible for method references. That is, as we do now, normalize the `site` using `skipTypeVars`, but also save the original `site` somewhere (as we already do). Note that the LookupHelper class has an `access` method, which is used to validate the result of the lookup (e.g. typically call `accessBase` on it). Effectively, this is a post-resolution step, pretty much like the one in `Attr`, so we can add whatever logic we want there (I think replicating the code in `Attr`  - see steps above - would be the best).
>> 
>> So, I don't think we need to add the new `isInherited` method - just overriding `access` to do the same thing we do in `Attr::selectSym` should be enough (I hope)
>
> In fact... looking more - I see that `ReferenceLookupHelper` already overrides `access`. But this class doesn't have `originalSite` so you can't add the new access check here. So, `MethodReferenceLookupHelper` would have to override, add the new access check and call the super method.

I gave it another try and updated the code. One of my experiments was on this line but not exactly what you are proposing and I was not very happy with the end result. I think now it should be good, thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16210#discussion_r1364357155

From mcimadamore at openjdk.org  Wed Oct 18 20:38:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 18 Oct 2023 20:38:49 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v7]
In-Reply-To: <gZVQoFI2p-rNua_HLJ6jxl1m3S8RTW10Si0FILBYd1Q=.b1fb7a88-78da-4e89-b108-0f0cafa0c1b7@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <gZVQoFI2p-rNua_HLJ6jxl1m3S8RTW10Si0FILBYd1Q=.b1fb7a88-78da-4e89-b108-0f0cafa0c1b7@github.com>
Message-ID: <-LccCS_5pJVCnB4uM1V1BpJw8RFSnyQlJfJAUxSdksQ=.b471319c-a624-490e-8e03-f069a9503a1f@github.com>

On Wed, 18 Oct 2023 18:22:00 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
>> 
>> 
>> import java.util.function.*;
>> 
>> class Test {
>>     private String asString() {
>>         return "bar";
>>     }
>> 
>>     static <T extends Test> Function<T, String> foo() {
>>         return T::asString;
>>     }
>> }
>> 
>> 
>> this code should be rejected on the grounds that ::asString is a private method in class `Test` and thus not a member of type variable `T`
>> 
>> TIA
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   another implementation

Looks very good, thanks!

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16210#pullrequestreview-1686098389

From vromero at openjdk.org  Wed Oct 18 21:11:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 18 Oct 2023 21:11:46 GMT
Subject: RFR: 8318160: javac does not reject private method reference with
 type-variable receiver [v7]
In-Reply-To: <-LccCS_5pJVCnB4uM1V1BpJw8RFSnyQlJfJAUxSdksQ=.b471319c-a624-490e-8e03-f069a9503a1f@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
 <gZVQoFI2p-rNua_HLJ6jxl1m3S8RTW10Si0FILBYd1Q=.b1fb7a88-78da-4e89-b108-0f0cafa0c1b7@github.com>
 <-LccCS_5pJVCnB4uM1V1BpJw8RFSnyQlJfJAUxSdksQ=.b471319c-a624-490e-8e03-f069a9503a1f@github.com>
Message-ID: <xYrvSHPXuAV9Ji-oYlFE_fKQ6J5yQzzI2PFfmzNbtA4=.28c97242-5471-4d72-8d05-93755eea3f91@github.com>

On Wed, 18 Oct 2023 20:36:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks very good, thanks!

thanks for the review! could you please review the CSR too? Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/16210#issuecomment-1769323012

From yuriy.maslyanko at oracle.com  Wed Oct 18 21:38:39 2023
From: yuriy.maslyanko at oracle.com (Yuriy Maslyanko)
Date: Wed, 18 Oct 2023 21:38:39 +0000
Subject: JEP 455: JLS change for switch expressions
Message-ID: <SJ0PR10MB5648E7E3FD03BD77724DD3B282D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>

Hi Angelos,

JCK team started working on JEP 455: Primitive types in Patterns, instanceof, and switch (Preview). Just noticed that in the draft spec, https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html, there is a change for the switch statement:

14.11 The switch Statement
The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-14.11-200)
->
The Expression is called the selector expression. The type of the selector expression can be either a primitive or a reference type.

But the corresponding assertion for switch expressions is not changed:

15.28. switch Expressions
The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-15.28-200)

Could you please take a look?

Thanks,
Yuriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231018/6466e6ab/attachment.htm>

From abimpoudis at openjdk.org  Wed Oct 18 22:12:10 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 18 Oct 2023 22:12:10 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v25]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <QZWZUKB_wSYb1x31iArJ5nBKO3mjtR6CNVUAPafSwr0=.81f2dd90-c304-4ca1-abdd-bc3fcb878533@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/248971be..fa6256b4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=23-24

  Stats: 38 lines in 2 files changed: 37 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From angelos.bimpoudis at oracle.com  Wed Oct 18 22:24:40 2023
From: angelos.bimpoudis at oracle.com (Angelos Bimpoudis)
Date: Wed, 18 Oct 2023 22:24:40 +0000
Subject: JEP 455: JLS change for switch expressions
In-Reply-To: <SJ0PR10MB5648E7E3FD03BD77724DD3B282D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>
References: <SJ0PR10MB5648E7E3FD03BD77724DD3B282D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>
Message-ID: <IA1PR10MB7515E24AB967B516C5F9E23B82D5A@IA1PR10MB7515.namprd10.prod.outlook.com>

Correct and good catch!

Spec updated.

Many thanks ?
________________________________
From: Yuriy Maslyanko <yuriy.maslyanko at oracle.com>
Sent: 18 October 2023 23:38
To: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Cc: compiler-dev at openjdk.org <compiler-dev at openjdk.org>
Subject: JEP 455: JLS change for switch expressions


Hi Angelos,



JCK team started working on JEP 455: Primitive types in Patterns, instanceof, and switch (Preview). Just noticed that in the draft spec, https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html, there is a change for the switch statement:



14.11 The switch Statement

The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-14.11-200)

->

The Expression is called the selector expression. The type of the selector expression can be either a primitive or a reference type.



But the corresponding assertion for switch expressions is not changed:



15.28. switch Expressions

The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-15.28-200)



Could you please take a look?



Thanks,

Yuriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231018/d8fe58b0/attachment-0001.htm>

From yuriy.maslyanko at oracle.com  Wed Oct 18 22:53:04 2023
From: yuriy.maslyanko at oracle.com (Yuriy Maslyanko)
Date: Wed, 18 Oct 2023 22:53:04 +0000
Subject: JEP 455: JLS change for switch expressions
In-Reply-To: <IA1PR10MB7515E24AB967B516C5F9E23B82D5A@IA1PR10MB7515.namprd10.prod.outlook.com>
References: <SJ0PR10MB5648E7E3FD03BD77724DD3B282D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>
 <IA1PR10MB7515E24AB967B516C5F9E23B82D5A@IA1PR10MB7515.namprd10.prod.outlook.com>
Message-ID: <SJ0PR10MB56481B1E5F2AFFDAF44E2B4A82D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>

Thanks Angelos!

From: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Sent: Wednesday, October 18, 2023 3:25 PM
To: Yuriy Maslyanko <yuriy.maslyanko at oracle.com>
Cc: compiler-dev at openjdk.org
Subject: Re: JEP 455: JLS change for switch expressions

Correct and good catch!

Spec updated.

Many thanks ?
________________________________
From: Yuriy Maslyanko <yuriy.maslyanko at oracle.com<mailto:yuriy.maslyanko at oracle.com>>
Sent: 18 October 2023 23:38
To: Angelos Bimpoudis <angelos.bimpoudis at oracle.com<mailto:angelos.bimpoudis at oracle.com>>
Cc: compiler-dev at openjdk.org<mailto:compiler-dev at openjdk.org> <compiler-dev at openjdk.org<mailto:compiler-dev at openjdk.org>>
Subject: JEP 455: JLS change for switch expressions


Hi Angelos,



JCK team started working on JEP 455: Primitive types in Patterns, instanceof, and switch (Preview). Just noticed that in the draft spec, https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html, there is a change for the switch statement:



14.11 The switch Statement

The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-14.11-200)

->

The Expression is called the selector expression. The type of the selector expression can be either a primitive or a reference type.



But the corresponding assertion for switch expressions is not changed:



15.28. switch Expressions

The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-15.28-200)



Could you please take a look?



Thanks,

Yuriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231018/07b3eda4/attachment.htm>

From darcy at openjdk.org  Thu Oct 19 04:46:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 19 Oct 2023 04:46:21 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <BLNhDFMfiSgtCj6kYK9M-26nHUjLuGYokJk4MFH_Lb8=.9b8460fb-3294-4043-9cdf-951c98da2410@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <BLNhDFMfiSgtCj6kYK9M-26nHUjLuGYokJk4MFH_Lb8=.9b8460fb-3294-4043-9cdf-951c98da2410@github.com>
Message-ID: <85PMsqkEMGwLNBjUYV8BVvkvZNBEouTE2Iw6Q2BxY7w=.4aea3771-11af-42ad-91a1-e853668fe096@github.com>

On Sun, 8 Oct 2023 05:48:28 GMT, Danny Thomas <duke at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos.
>
> After much head scratching attempting to run the benchmarks for 8309130, I realised this change broke microbenchmarks:
> 
> $ make test TEST="micro:java.lang.ArraysSort"
> Building target 'test' in configuration 'linux-x86_64-server-release'
> ...
> Test selection 'micro:java.lang.ArraysSort', will run:
> * micro:java.lang.ArraysSort
> 
> Running test 'micro:java.lang.ArraysSort'
> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable to find the resource: /META-INF/BenchmarkList
> 	at org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98)
> 	at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124)
> 	at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252)
> 	at org.openjdk.jmh.runner.Runner.run(Runner.java:208)
> 	at org.openjdk.jmh.Main.main(Main.java:71)
> Finished running test 'micro:java.lang.ArraysSort'
> Test report is stored in build/linux-x86_64-server-release/test-results/micro_java_lang_ArraysSort

> Hello @DanielThomas, thank you reporting and narrowing down the microbenchmark failures. This is now being addressed in https://bugs.openjdk.org/browse/JDK-8317802.

Thanks for taking care of that issue @jaikiran .

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1769881588

From cstein at openjdk.org  Thu Oct 19 10:37:49 2023
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 19 Oct 2023 10:37:49 GMT
Subject: RFR: 8307168: Inconsistent validation and handling of --system flag
 arguments
Message-ID: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>

Please review these changes that fix a bug in `javac`'s validation and handling of `--system` flag arguments.

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

Commit messages:
 -  8307168: Inconsistent validation and handling of --system flag arguments

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

PR: https://git.openjdk.org/jdk/pull/16264

From ron.pressler at oracle.com  Thu Oct 19 21:47:14 2023
From: ron.pressler at oracle.com (Ron Pressler)
Date: Thu, 19 Oct 2023 21:47:14 +0000
Subject: JEP 458: Launch Multi-File Source-Code Program: Inferring the root of
 the source tree
Message-ID: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>

JEP 458: Launch Multi-File Source-Code Programs (https://openjdk.org/jeps/458) describes a mechanism by which the root of a source directory is computed (for the purpose of locating other referenced classes) from the path of the launched file and its directory; that root is then used implicitly as if `--source-path <root>` has been passed to javac. The algorithm for inferring the source compares the .java file?s package against its filesystem path and ?subtracts? the package from the suffix of the filesystem path.

For example, if in directory dir/a/b/c I have the file C.java and I launch it as a program with `java dir/a/b/c/C.java` then:

- If C.java declares its package to be a.b.c then the root of the source tree is inferred to be dir
- If C.java declares its package to be b.c then the root of the source tree is inferred to be dir/a
- If C.java declares its package to be c then the root of the source tree is inferred to be dir/a/b
- If C.java doesn?t declare a package (i.e. it?s in the unnamed package), then the root of the source tree is inferred to be dir/a/b/c
- If C.java declares its package to be p (which doesn?t match any suffix of its path), then we get an error.

The current working directory from which we invoke `java` is ignored.

This is different from the way javac behaves. If we run `javac dir/a/b/c/C.java`, then, for the purpose of resolving other referenced classes, the root of the tree is always the current working directory, and the package that C.java declares is ignored (it can be p and the compilation will succeed).

The algorithm for inferring the root of the source tree in the source-code launcher was chosen so that programs could be easily launched directly from source from any working directory without explicitly setting a source tree root, under the reasonable assumption that source files are placed as we would expect in a project. I would like to get some feedback about the algorithm?s suitability and reasonableness.

? Ron



From maurizio.cimadamore at oracle.com  Thu Oct 19 23:37:43 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Fri, 20 Oct 2023 00:37:43 +0100
Subject: JEP 458: Launch Multi-File Source-Code Program: Inferring the
 root of the source tree
In-Reply-To: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>
References: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>
Message-ID: <4fe0f1e8-4db6-4d39-a5f1-feb717e3a3f6@oracle.com>

The algorithm you describe seems reasonable, at least from the 
perspective of the developer invoking the java launcher.

It does add some complexity because now you need to first be able to 
parse the sourcefile in question in the first place in order to be able 
to determine what the source path of the compilation should be, so 
effectively you end up with a chicken and egg problem. It's not a big 
issue for the launcher - given that the launcher is built on top of 
javac. I see that the launcher code spins a quick parsing of the source, 
in a separate java compilation environment, just for this purpose:

https://github.com/openjdk/jdk/blob/093ab1cef7383323deb74bffa511b81109ca4dd6/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java#L53

I think that's ok. Also, the logic for "subtracting" the package part 
from the path doesn't seem too daunting, and is made relatively robust 
and portable by the use of Paths:

https://github.com/openjdk/jdk/blob/093ab1cef7383323deb74bffa511b81109ca4dd6/src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/ProgramDescriptor.java#L73

That said, if you are wondering whether the behavior of javac could 
eventually be aligned to match this, I'd be more skeptical, as the 
chicken and egg problem would become more manifest I think, as you'd 
need to spin up a java compiler while launching another... while we 
might find some workarouns in this direction, I'm not sure it'd be worth 
it, and it will also be a biggie behavioral compatibility issue (for javac).

Summing up, I think your approach is workable. I don't know exactly (as 
I had not have the time to play around with the new launcher much) how 
much this algorithm _exactly_ brings on the table. Using the current 
folder as the source path is not a completely terrible default, and has 
the enormous advantage of not requiring any parsing step, so it's a very 
pragmatical one from a tooling perspective. But ultimately, I believe 
that, in the context of a JEP like this, usability has to take the front 
seat. I imagine there are some examples and use cases where the proposed 
algorithm worked and the "classic" one didn't?

P.S.
I suppose the plan is to only support classpath applications only - 
otherwise there's also a module sourcepath to infer, and that could be a 
bit trickier :-)

Cheers
Maurizio


On 19/10/2023 22:47, Ron Pressler wrote:
> The current working directory from which we invoke `java` is ignored. 
> This is different from the way javac behaves. If we run `javac 
> dir/a/b/c/C.java`, then, for the purpose of resolving other referenced 
> classes, the root of the tree is always the current working directory, 
> and the package that C.java declares is ignored (it can be p and the 
> compilation will succeed). The algorithm for inferring the root of the 
> source tree in the source-code launcher was chosen so that programs 
> could be easily launched directly from source from any working 
> directory without explicitly setting a source tree root, under the 
> reasonable assumption that source files are placed as we would expect 
> in a project. I would like to get some feedback about the algorithm?s 
> suitability and reasonableness.

From asotona at openjdk.org  Fri Oct 20 08:01:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 20 Oct 2023 08:01:57 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v22]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <F-7Cov427C2TkdeRLHwwciSZtQnUamvdHS4GWsyD1zI=.88c98fd4-b3f3-4477-b959-462a70bed3e2@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 353 commits:

 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - removed trailing space
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - package info javadoc improvements
 - removed obsolete exports from BuildMicrobenchmark.gmk
 - Merge branch 'master' into JDK-8308753-preview
 - added @sealedGraph tags
 - fixed exception type thrown from CodeImpl
 - added constraint to throw on an attempt to parse unknown classfile version
   + test
 - removed AttributeMapper::validSince
 - ... and 343 more: https://git.openjdk.org/jdk/compare/4812caba...9b77afb3

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=21
  Stats: 32121 lines in 764 files changed: 14618 ins; 14049 del; 3454 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From ron.pressler at oracle.com  Fri Oct 20 08:28:12 2023
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 20 Oct 2023 08:28:12 +0000
Subject: JEP 458: Launch Multi-File Source-Code Program: Inferring the
 root of the source tree
In-Reply-To: <4fe0f1e8-4db6-4d39-a5f1-feb717e3a3f6@oracle.com>
References: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>
 <4fe0f1e8-4db6-4d39-a5f1-feb717e3a3f6@oracle.com>
Message-ID: <B7F1F1EF-14A9-4936-B95E-B8797C9B83CB@oracle.com>



> On 20 Oct 2023, at 00:37, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> That said, if you are wondering whether the behavior of javac could eventually be aligned to match this, I'd be more skeptical,

I wasn?t thinking about applying this to javac.

> 
> Summing up, I think your approach is workable. I don't know exactly (as I had not have the time to play around with the new launcher much) how much this algorithm _exactly_ brings on the table. Using the current folder as the source path is not a completely terrible default, and has the enormous advantage of not requiring any parsing step, so it's a very pragmatical one from a tooling perspective. But ultimately, I believe that, in the context of a JEP like this, usability has to take the front seat. I imagine there are some examples and use cases where the proposed algorithm worked and the "classic" one didn't?

It?s mostly so that changing the current directory is not required to launch the program, which may be common when the source tree root is a src directory under a project?s root directory (so you can launch with `java src/pkg/Main.java`). It doesn?t matter as much for javac, which is now most commonly invoked indirectly by tools.


> I suppose the plan is to only support classpath applications only - otherwise there's also a module sourcepath to infer, and that could be a bit trickier :-)

A *single* module is supported, too, if a module-info.java is found at the root of the source tree: https://openjdk.org/jeps/458#Modular-source-code-programs

? Ron





From acobbs at openjdk.org  Fri Oct 20 14:26:17 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 20 Oct 2023 14:26:17 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v19]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <uLl87K3nsJZZFgpVisFG_4CE6NDZJfyg8Zp0UDXX41U=.cc07aa68-4b4e-47da-be1f-eb2867a991b5@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Merge branch 'master' into SuperInit
 - Reword new errors to use the JLS term for "explicit constructor invocation".
 - After further review, revert 599d761 to avoid mutable state lying around.
 - Address review comments relating to error messages.
 - Have RefBeforeCtorCalledError extend StaticError and customize debug strings.
 - Change variable name "statik" -> "isStatic" per review recommendation.
 - Remove obsolete flag "constructorArgs".
 - Change the error message to match the applicable spec rule.
 - Merge branch 'master' into SuperInit
 - Eliminate "isSelfCall" flag, which is now made obsolete by "ctorPrologue".
 - ... and 29 more: https://git.openjdk.org/jdk/compare/17535c34...99a277e5

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

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=18
  Stats: 1498 lines in 27 files changed: 1156 ins; 225 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

PR: https://git.openjdk.org/jdk/pull/13656

From jjg at openjdk.org  Fri Oct 20 18:36:37 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 20 Oct 2023 18:36:37 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: <DrKq7j06dGayshzgo6rvbv1SrmCgbf-ghiw6pJegmko=.c270e3e0-ee0b-4a95-bc2b-cfa24eb30dcf@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
 <DrKq7j06dGayshzgo6rvbv1SrmCgbf-ghiw6pJegmko=.c270e3e0-ee0b-4a95-bc2b-cfa24eb30dcf@github.com>
Message-ID: <ms1vMPUL0o2P7FJdMqqpkRLVw4Cige9-eChnoNZrPOc=.6f2cb2a5-3c02-46a8-9b44-4d007b0bfd0e@github.com>

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

The proposed name `jdk.compiler.graal` makes it seem like the module is strongly related to the `jdk.compiler` module, which contains `javac` and related tools, whereas these modules are completely unrelated.

Is there not a better name that can be used?

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

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773211363

From mr at openjdk.org  Fri Oct 20 20:13:35 2023
From: mr at openjdk.org (Mark Reinhold)
Date: Fri, 20 Oct 2023 20:13:35 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v3]
In-Reply-To: <DrKq7j06dGayshzgo6rvbv1SrmCgbf-ghiw6pJegmko=.c270e3e0-ee0b-4a95-bc2b-cfa24eb30dcf@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
 <DrKq7j06dGayshzgo6rvbv1SrmCgbf-ghiw6pJegmko=.c270e3e0-ee0b-4a95-bc2b-cfa24eb30dcf@github.com>
Message-ID: <6GSrZIWvORLQC7cBdvhMRKa7lKfEsHqp1Umq82YEZg0=.3c14d749-f5e4-49f1-ab54-17a0d8f2c78d@github.com>

On Fri, 20 Oct 2023 15:45:50 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>
> Doug Simon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-fix since tags to reflect current JDK release

Jon makes a good point. If memory serves, wasn?t the name `jdk.graal.compiler` suggested previously? That would avoid the overlap with the name of the existing `jdk.compiler` module.

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

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773335627

From attila.kelemen85 at gmail.com  Fri Oct 20 21:09:38 2023
From: attila.kelemen85 at gmail.com (Attila Kelemen)
Date: Fri, 20 Oct 2023 23:09:38 +0200
Subject: JEP 458: Launch Multi-File Source-Code Program: Inferring the
 root of the source tree
In-Reply-To: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>
References: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>
Message-ID: <CAKDaPBd39Ou1gtsY+DxxfpUSt-XAvLv-_AZH7ouphSteg4mW6Q@mail.gmail.com>

I have a problem with the last point (the error). Because I'm trying to
imagine when would someone put the main class into a package, if the goal
is to just edit java files directly, and run them without explicit
compilation from the command line. It seems to me that it would be just
masochistic. One reason I can imagine someone has packages is if this
direct java usage is done as a temporary measure, and actually sources were
copied from a "normal" code base. In this case however, it would feel awful
to type in the long package path (which in normal package naming convention
is often tediously long), I would just want to trim the common package
prefix from the path.

So, what I would find a more convenient behaviour, if java can't unwind the
full package, then just assumes that directory is the root (up to the point
it could unwind), and all files under it have the unmatched package prefix.
For example, if I do `java dir/b/c/C.java`, and `C.java` declares its
package to be `a.b.c`, then `dir` is the root directory, and if it needs
the class `a.b.d.X`, then it would search it in `dir/b/d/X.java`.

In fact, I would love if I didn't have to create these deeply nested
directories in normal projects as well, but that is pretty much only on
IDEs (that is they behave awkwardly, if you try to do this), because -
using Gradle for example - the build tool will just list all the individual
java files to javac anyway, and at that point javac couldn't care less
about directories, and the build works fine.

Attila

Ron Pressler <ron.pressler at oracle.com> ezt ?rta (id?pont: 2023. okt. 19.,
Cs, 23:47):

> JEP 458: Launch Multi-File Source-Code Programs (
> https://openjdk.org/jeps/458) describes a mechanism by which the root of
> a source directory is computed (for the purpose of locating other
> referenced classes) from the path of the launched file and its directory;
> that root is then used implicitly as if `--source-path <root>` has been
> passed to javac. The algorithm for inferring the source compares the .java
> file?s package against its filesystem path and ?subtracts? the package from
> the suffix of the filesystem path.
>
> For example, if in directory dir/a/b/c I have the file C.java and I launch
> it as a program with `java dir/a/b/c/C.java` then:
>
> - If C.java declares its package to be a.b.c then the root of the source
> tree is inferred to be dir
> - If C.java declares its package to be b.c then the root of the source
> tree is inferred to be dir/a
> - If C.java declares its package to be c then the root of the source tree
> is inferred to be dir/a/b
> - If C.java doesn?t declare a package (i.e. it?s in the unnamed package),
> then the root of the source tree is inferred to be dir/a/b/c
> - If C.java declares its package to be p (which doesn?t match any suffix
> of its path), then we get an error.
>
> The current working directory from which we invoke `java` is ignored.
>
> This is different from the way javac behaves. If we run `javac
> dir/a/b/c/C.java`, then, for the purpose of resolving other referenced
> classes, the root of the tree is always the current working directory, and
> the package that C.java declares is ignored (it can be p and the
> compilation will succeed).
>
> The algorithm for inferring the root of the source tree in the source-code
> launcher was chosen so that programs could be easily launched directly from
> source from any working directory without explicitly setting a source tree
> root, under the reasonable assumption that source files are placed as we
> would expect in a project. I would like to get some feedback about the
> algorithm?s suitability and reasonableness.
>
> ? Ron
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231020/a7a78042/attachment-0001.htm>

From ron.pressler at oracle.com  Fri Oct 20 21:20:42 2023
From: ron.pressler at oracle.com (Ron Pressler)
Date: Fri, 20 Oct 2023 21:20:42 +0000
Subject: [External] : Re: JEP 458: Launch Multi-File Source-Code Program:
 Inferring the root of the source tree
In-Reply-To: <CAKDaPBd39Ou1gtsY+DxxfpUSt-XAvLv-_AZH7ouphSteg4mW6Q@mail.gmail.com>
References: <35D03E2D-8070-4E91-93D4-6E4E49FF3873@oracle.com>
 <CAKDaPBd39Ou1gtsY+DxxfpUSt-XAvLv-_AZH7ouphSteg4mW6Q@mail.gmail.com>
Message-ID: <6A7BA99E-AB7A-40D0-9B6F-802A92E25699@oracle.com>

I think your idea is both interesting and reasonable, but more importantly, I think it?s compatible with the simpler one presented here because it accepts something that the current behaviour rejects. So we may not have enough time to think about it and implement it in 22 (we want to target 458 to 22), but we can add that enhancement later.

? Ron

> On 20 Oct 2023, at 22:09, Attila Kelemen <attila.kelemen85 at gmail.com> wrote:
> 
> I have a problem with the last point (the error). Because I'm trying to imagine when would someone put the main class into a package, if the goal is to just edit java files directly, and run them without explicit compilation from the command line. It seems to me that it would be just masochistic. One reason I can imagine someone has packages is if this direct java usage is done as a temporary measure, and actually sources were copied from a "normal" code base. In this case however, it would feel awful to type in the long package path (which in normal package naming convention is often tediously long), I would just want to trim the common package prefix from the path.
> 
> So, what I would find a more convenient behaviour, if java can't unwind the full package, then just assumes that directory is the root (up to the point it could unwind), and all files under it have the unmatched package prefix. For example, if I do `java dir/b/c/C.java`, and `C.java` declares its package to be `a.b.c`, then `dir` is the root directory, and if it needs the class `a.b.d.X`, then it would search it in `dir/b/d/X.java`.
> 
> In fact, I would love if I didn't have to create these deeply nested directories in normal projects as well, but that is pretty much only on IDEs (that is they behave awkwardly, if you try to do this), because - using Gradle for example - the build tool will just list all the individual java files to javac anyway, and at that point javac couldn't care less about directories, and the build works fine.
> 
> Attila
> 
> Ron Pressler <ron.pressler at oracle.com> ezt ?rta (id?pont: 2023. okt. 19., Cs, 23:47):
> JEP 458: Launch Multi-File Source-Code Programs (https://openjdk.org/jeps/458) describes a mechanism by which the root of a source directory is computed (for the purpose of locating other referenced classes) from the path of the launched file and its directory; that root is then used implicitly as if `--source-path <root>` has been passed to javac. The algorithm for inferring the source compares the .java file?s package against its filesystem path and ?subtracts? the package from the suffix of the filesystem path.
> 
> For example, if in directory dir/a/b/c I have the file C.java and I launch it as a program with `java dir/a/b/c/C.java` then:
> 
> - If C.java declares its package to be a.b.c then the root of the source tree is inferred to be dir
> - If C.java declares its package to be b.c then the root of the source tree is inferred to be dir/a
> - If C.java declares its package to be c then the root of the source tree is inferred to be dir/a/b
> - If C.java doesn?t declare a package (i.e. it?s in the unnamed package), then the root of the source tree is inferred to be dir/a/b/c
> - If C.java declares its package to be p (which doesn?t match any suffix of its path), then we get an error.
> 
> The current working directory from which we invoke `java` is ignored.
> 
> This is different from the way javac behaves. If we run `javac dir/a/b/c/C.java`, then, for the purpose of resolving other referenced classes, the root of the tree is always the current working directory, and the package that C.java declares is ignored (it can be p and the compilation will succeed).
> 
> The algorithm for inferring the root of the source tree in the source-code launcher was chosen so that programs could be easily launched directly from source from any working directory without explicitly setting a source tree root, under the reasonable assumption that source files are placed as we would expect in a project. I would like to get some feedback about the algorithm?s suitability and reasonableness.
> 
> ? Ron
> 
> 


From darcy at openjdk.org  Sat Oct 21 01:44:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 21 Oct 2023 01:44:42 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing
In-Reply-To: <J5FV_g0pT-VKq8I5-9Jg0Q1G5u5LHTtmA9zX-HUN64o=.55324e37-9f2a-4e49-8e5b-7e150cae1510@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
 <L9f6RG36zl89Hagzn-Nba6sdIOh168DW3IehpbpUBy0=.3e73cb95-ebc1-48cb-993b-f230cf6b9dfa@github.com>
 <J5FV_g0pT-VKq8I5-9Jg0Q1G5u5LHTtmA9zX-HUN64o=.55324e37-9f2a-4e49-8e5b-7e150cae1510@github.com>
Message-ID: <n8w-GhXtubyEQTs58LG2v5mQ_w8ZxrCeFg-ywgA8ueE=.4acd4926-9784-49c5-a92e-56a801879676@github.com>

On Sun, 10 Sep 2023 22:57:30 GMT, Rob Bygrave <duke at openjdk.org> wrote:

> > This patch isn't aimed to remove AP. This aims to avoid unintentional AP pollutions in classpath
> 
> Yes, I understand that.
> 
> > Such classpath separation have already been promoted by build tools like Gradle.
> 
> **_BUT_** it has **_NOT_** been promoted by **_Maven_**. In the bug report and in this PR I do not see any explicit recognition of how this change will impact the community that is using Maven and I am suggesting that this is a significant proportion of the community.
> 
> For example, all the libraries that use annotation processing that document maven use could be impacted along the lines that their documentation will now be at least misleading (and sometimes incorrect).
> 
> This change might indeed be a good long term change but it seems to be being made without any recognition or understanding of how impactful it will be.

Maven is listed as a participant in the OpenJDK Quality Outreach effort (https://wiki.openjdk.org/display/quality/Quality+Outreach).

The prior change of the javac emitting the note was explicitly raised on the quality discuss alias in July 2023 (https://mail.openjdk.org/pipermail/quality-discuss/2023-July/thread.html), ahead of the GA of JDK 21 in September.

The change in this PR is likewise publicized this the October 2023 quality discuss message (https://mail.openjdk.org/pipermail/quality-discuss/2023-October/001129.html), months ahead of the expected GA of JDK 23 in March 2024.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1773592750

From dnsimon at openjdk.org  Sat Oct 21 10:56:01 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 21 Oct 2023 10:56:01 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
Message-ID: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.

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

 - Merge tag 'jdk-22+18' into JDK-8318027_rename
   
   Added tag jdk-22+18 for changeset 3105538d
 - rename jdk.compiler.graal to jdk.graal.compiler
 - re-fix since tags to reflect current JDK release
 - fix copyright dates and @since tags to reflect history
 - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16189/files
  - new: https://git.openjdk.org/jdk/pull/16189/files/193e22a6..3014f40f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16189&range=02-03

  Stats: 11380 lines in 399 files changed: 5944 ins; 1943 del; 3493 mod
  Patch: https://git.openjdk.org/jdk/pull/16189.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16189/head:pull/16189

PR: https://git.openjdk.org/jdk/pull/16189

From dnsimon at openjdk.org  Sat Oct 21 11:35:36 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Sat, 21 Oct 2023 11:35:36 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: <GEvr-mtd4JFBhA6dWHbYsUk-xjZJ2Vs__HCFPDTQ4FQ=.a5448150-6af6-4e6b-9c61-12e7b236bac3@github.com>

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Based on external discussion, agreement has been reached to rename to `jdk.graal.compiler` instead of `jdk.compiler.graal`.
Not only does this avoid the confusion with `jdk.compiler` pointed out by @jonathan-gibbons but it also establishes the namespace `jdk.graal` for Graal subprojects.

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

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1773764186

From mli at openjdk.org  Sun Oct 22 11:25:30 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 22 Oct 2023 11:25:30 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: <nIa5dKN7C0FhmucW15z2L_s3N3i89Q6GHHdhThSuy9U=.eb348933-f258-4621-be65-a67b5985ee60@github.com>

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1691416502

From alanb at openjdk.org  Mon Oct 23 12:21:31 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Oct 2023 12:21:31 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: <4GB8VGyiUeacXRu-XLjkdBQ31nDFKKH9lAaYRzl3viM=.19809082-209a-440c-b564-c2fbf0654d2b@github.com>

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16189#pullrequestreview-1692387518

From dnsimon at openjdk.org  Mon Oct 23 13:18:49 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 23 Oct 2023 13:18:49 GMT
Subject: RFR: 8318027: Support alternative name to jdk.internal.vm.compiler
 [v4]
In-Reply-To: <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
 <3cPdFOlprreuWMJWDC2aUHEWSPAitU2OBMohasOnVao=.ed12ffe5-b4e9-40bb-ba62-56b6d14caf4e@github.com>
Message-ID: <GTuK-qHCDpLAJuxHcEIjolPfBwUKgKZOoBeAII9ORiM=.dbf62897-cd31-4f59-b25e-3f95a69b97dc@github.com>

On Sat, 21 Oct 2023 10:56:01 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module ren
 aming, including adjusting the qualified export.
>> 
>> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186
>
> Doug Simon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge tag 'jdk-22+18' into JDK-8318027_rename
>    
>    Added tag jdk-22+18 for changeset 3105538d
>  - rename jdk.compiler.graal to jdk.graal.compiler
>  - re-fix since tags to reflect current JDK release
>  - fix copyright dates and @since tags to reflect history
>  - rename jdk.internal.vm.compiler* to jdk.compiler.graal*

Thanks for all the reviews and careful consideration on this naming change. It will have long term consequences so getting it right is important.

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

PR Comment: https://git.openjdk.org/jdk/pull/16189#issuecomment-1775167880

From dnsimon at openjdk.org  Mon Oct 23 13:18:52 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Mon, 23 Oct 2023 13:18:52 GMT
Subject: Integrated: 8318027: Support alternative name to
 jdk.internal.vm.compiler
In-Reply-To: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
References: <efbqW9kVDcxz5LlcnSWHWVIthn4uxTITf1myoF_PEng=.c3d7508f-639d-4f78-b554-b140d88be8ff@github.com>
Message-ID: <HNhAXJmb0XqdNqQCSrISpysxvAFdkFv4R3oxKa_UwmU=.eb6e6e5a-a1b7-4135-a3ac-fd5aed6fda8b@github.com>

On Fri, 13 Oct 2023 16:28:19 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

> The Graal code base has [renamed](https://github.com/oracle/graal/commit/1e41203d10db321f86723eac90f6cd0573b08b33) its module to `jdk.compiler.graal` as part of preparations for Project Galahad. Due to the way Java modules work, this requires a JDK change. The core of the issue is that the [service](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L37) by which HotSpot requests a Graal compilation is defined in JVMCI. Since JVMCI is in the boot layer, the service can only be implemented by a provider in the boot layer and the package defining the service must be exported to the provider's defining module. This export currently targets [`jdk.internal.vm.compiler`](https://github.com/openjdk/jdk/blob/56aa1e8dc8047cbc29d554889c64beb6eca0b8eb/src/jdk.internal.vm.ci/share/classes/module-info.java#L28) and so the binding fails for the new Graal module. To address this, this PR reflects the Graal module rena
 ming, including adjusting the qualified export.
> 
> Edit: The target of the rename is now `jdk.graal.compiler` - see https://github.com/openjdk/jdk/pull/16189#issuecomment-1773764186

This pull request has now been integrated.

Changeset: bd22d238
Author:    Doug Simon <dnsimon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd22d2381fa3f21b113d5b8ef95fe15cec50b066
Stats:     40 lines in 10 files changed: 0 ins; 14 del; 26 mod

8318027: Support alternative name to jdk.internal.vm.compiler

Reviewed-by: erikj, ihse, kvn, alanb, mli

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

PR: https://git.openjdk.org/jdk/pull/16189

From prappo at openjdk.org  Mon Oct 23 15:12:05 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 23 Oct 2023 15:12:05 GMT
Subject: RFR: 8317289: javadoc fails with -sourcepath if module-info.java
 contains import statements
Message-ID: <SPmBmQBMBzztHScj5Kq7nEMZxD4Sv8JWmF5lL6siAnc=.3405e826-c2e5-4205-81f7-0a1ea0bdba29@github.com>

Please review a fix to a bug in processing of the `sourcepath` javadoc option.

The bug is that when `-sourcepath`/`--source-path` is specified, retrieving a module name does not account for any import statements in `module-info.java`.

Originally, I was thinking to propose the following simple fix on the `javac` side:


diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
index b25c99d3b06..e046b3d310e 100644
--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
@@ -1322,10 +1322,9 @@ public static boolean isModuleInfo(JCCompilationUnit tree) {
     }
 
     public static JCModuleDecl getModule(JCCompilationUnit t) {
-        if (t.defs.nonEmpty()) {
-            JCTree def = t.defs.head;
-            if (def.hasTag(MODULEDEF))
-                return (JCModuleDecl) def;
+        for (var d = t.defs; d.nonEmpty(); d = d.tail) {
+            if (d.head.hasTag(MODULEDEF))
+                return (JCModuleDecl) d.head;
         }
         return null;
     }


However, Jan Lahoda (@lahodaj) told me that `JCCompilationUnit` already provides this functionality in a like-named method:


        @DefinedBy(Api.COMPILER_TREE)
        public JCModuleDecl getModule() {
            return getModuleDecl();
        }
...
        public JCModuleDecl getModuleDecl() {
            for (JCTree tree : defs) {
                if (tree.hasTag(MODULEDEF)) {
                    return (JCModuleDecl) tree;
                }
            }

            return null;
        }


So the actual fix in this PR is even simpler than my original fix.

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

Commit messages:
 - Fix
 - Test

Changes: https://git.openjdk.org/jdk/pull/16312/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16312&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317289
  Stats: 69 lines in 3 files changed: 56 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/16312.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16312/head:pull/16312

PR: https://git.openjdk.org/jdk/pull/16312

From jlahoda at openjdk.org  Mon Oct 23 15:17:27 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 23 Oct 2023 15:17:27 GMT
Subject: RFR: 8317289: javadoc fails with -sourcepath if module-info.java
 contains import statements
In-Reply-To: <SPmBmQBMBzztHScj5Kq7nEMZxD4Sv8JWmF5lL6siAnc=.3405e826-c2e5-4205-81f7-0a1ea0bdba29@github.com>
References: <SPmBmQBMBzztHScj5Kq7nEMZxD4Sv8JWmF5lL6siAnc=.3405e826-c2e5-4205-81f7-0a1ea0bdba29@github.com>
Message-ID: <TBFZoaesliy34nG2W09SWkn_rTslqrmxdg2cIcZm9iY=.15e727ee-0ebb-47ad-9aab-4859a335b3b2@github.com>

On Mon, 23 Oct 2023 15:04:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review a fix to a bug in processing of the `sourcepath` javadoc option.
> 
> The bug is that when `-sourcepath`/`--source-path` is specified, retrieving a module name does not account for any import statements in `module-info.java`.
> 
> Originally, I was thinking to propose the following simple fix on the `javac` side:
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
> index b25c99d3b06..e046b3d310e 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
> @@ -1322,10 +1322,9 @@ public static boolean isModuleInfo(JCCompilationUnit tree) {
>      }
>  
>      public static JCModuleDecl getModule(JCCompilationUnit t) {
> -        if (t.defs.nonEmpty()) {
> -            JCTree def = t.defs.head;
> -            if (def.hasTag(MODULEDEF))
> -                return (JCModuleDecl) def;
> +        for (var d = t.defs; d.nonEmpty(); d = d.tail) {
> +            if (d.head.hasTag(MODULEDEF))
> +                return (JCModuleDecl) d.head;
>          }
>          return null;
>      }
> 
> 
> However, Jan Lahoda (@lahodaj) told me that `JCCompilationUnit` already provides this functionality in a like-named method:
> 
> 
>         @DefinedBy(Api.COMPILER_TREE)
>         public JCModuleDecl getModule() {
>             return getModuleDecl();
>         }
> ...
>         public JCModuleDecl getModuleDecl() {
>             for (JCTree tree : defs) {
>                 if (tree.hasTag(MODULEDEF)) {
>                     return (JCModuleDecl) tree;
>                 }
>             }
> 
>             return null;
>         }
> 
> 
> So the actual fix in this PR is even simpler than my original fix.

Looks good to me, thanks!

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16312#pullrequestreview-1692842985

From vromero at openjdk.org  Mon Oct 23 20:39:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 23 Oct 2023 20:39:47 GMT
Subject: RFR: 8316470: Incorrect error location for
 "invalid permits clause" depending on file order
In-Reply-To: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>
References: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>
Message-ID: <EyFMS3o9RbUnUhWBupDcpVz1GQRnYruzb4seZEeJ4TA=.32c589f0-dd96-4c69-bd77-29d749bcd70e@github.com>

On Tue, 17 Oct 2023 15:10:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like (in two different files, but accessible through source path):
> 
> class Main extends C {}
> 
> 
> sealed class C {} //does not permit Main
> 
> 
> and a javac process that will start attribution with `Main`. As part of `Main` attribution, its superclasses will be attributed, hence `C` will be attributed. And there will be a sealing error reported for `C` (missing permitted). But, the source in the logger will still be set to `Main`, and hence the report will be reported at a weird place in `Main`, not in `C`.
> 
> The proposed solution is simple: move the code to set the source to logger (and related code) before the sealed checks. The diff looks scary, but it is movement of several lines up, and whitespace changes.

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16221#pullrequestreview-1693480827

From prappo at openjdk.org  Tue Oct 24 08:49:40 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 24 Oct 2023 08:49:40 GMT
Subject: Integrated: 8317289: javadoc fails with -sourcepath if
 module-info.java contains import statements
In-Reply-To: <SPmBmQBMBzztHScj5Kq7nEMZxD4Sv8JWmF5lL6siAnc=.3405e826-c2e5-4205-81f7-0a1ea0bdba29@github.com>
References: <SPmBmQBMBzztHScj5Kq7nEMZxD4Sv8JWmF5lL6siAnc=.3405e826-c2e5-4205-81f7-0a1ea0bdba29@github.com>
Message-ID: <UTqGROmnvt3PJdZHLB680jVP1tb6u7lxkPQkvm0dP1o=.312d65b9-8524-4385-9516-be32fec66875@github.com>

On Mon, 23 Oct 2023 15:04:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review a fix to a bug in processing of the `sourcepath` javadoc option.
> 
> The bug is that when `-sourcepath`/`--source-path` is specified, retrieving a module name does not account for any import statements in `module-info.java`.
> 
> Originally, I was thinking to propose the following simple fix on the `javac` side:
> 
> 
> diff --git a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
> index b25c99d3b06..e046b3d310e 100644
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java
> @@ -1322,10 +1322,9 @@ public static boolean isModuleInfo(JCCompilationUnit tree) {
>      }
>  
>      public static JCModuleDecl getModule(JCCompilationUnit t) {
> -        if (t.defs.nonEmpty()) {
> -            JCTree def = t.defs.head;
> -            if (def.hasTag(MODULEDEF))
> -                return (JCModuleDecl) def;
> +        for (var d = t.defs; d.nonEmpty(); d = d.tail) {
> +            if (d.head.hasTag(MODULEDEF))
> +                return (JCModuleDecl) d.head;
>          }
>          return null;
>      }
> 
> 
> However, Jan Lahoda (@lahodaj) told me that `JCCompilationUnit` already provides this functionality in a like-named method:
> 
> 
>         @DefinedBy(Api.COMPILER_TREE)
>         public JCModuleDecl getModule() {
>             return getModuleDecl();
>         }
> ...
>         public JCModuleDecl getModuleDecl() {
>             for (JCTree tree : defs) {
>                 if (tree.hasTag(MODULEDEF)) {
>                     return (JCModuleDecl) tree;
>                 }
>             }
> 
>             return null;
>         }
> 
> 
> So the actual fix in this PR is even simpler than my original fix.

This pull request has now been integrated.

Changeset: fd332da1
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fd332da1c8a689e91b7124fc342f02b6e0d3dff5
Stats:     69 lines in 3 files changed: 56 ins; 10 del; 3 mod

8317289: javadoc fails with -sourcepath if module-info.java contains import statements

Reviewed-by: jlahoda

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

PR: https://git.openjdk.org/jdk/pull/16312

From jlahoda at openjdk.org  Tue Oct 24 12:21:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 24 Oct 2023 12:21:45 GMT
Subject: Integrated: 8316470: Incorrect error location for
 "invalid permits clause" depending on file order
In-Reply-To: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>
References: <f31KnB-76gil6w_taXjfl4wDcYWNgmrIBEgruLjdeaw=.d7dd609c-27f5-423b-8842-64c581d8b602@github.com>
Message-ID: <yh7rO2bJEB4eIaSsrPzFSv2n26DBua0W4001Gz2Dasc=.f3890318-11bf-4f80-b827-a0661496a6b2@github.com>

On Tue, 17 Oct 2023 15:10:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Consider code like (in two different files, but accessible through source path):
> 
> class Main extends C {}
> 
> 
> sealed class C {} //does not permit Main
> 
> 
> and a javac process that will start attribution with `Main`. As part of `Main` attribution, its superclasses will be attributed, hence `C` will be attributed. And there will be a sealing error reported for `C` (missing permitted). But, the source in the logger will still be set to `Main`, and hence the report will be reported at a weird place in `Main`, not in `C`.
> 
> The proposed solution is simple: move the code to set the source to logger (and related code) before the sealed checks. The diff looks scary, but it is movement of several lines up, and whitespace changes.

This pull request has now been integrated.

Changeset: bf1a14e3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf1a14e3672b7d92b10d16210faf4fd99a860731
Stats:     279 lines in 2 files changed: 178 ins; 31 del; 70 mod

8316470: Incorrect error location for "invalid permits clause" depending on file order

Reviewed-by: vromero

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

PR: https://git.openjdk.org/jdk/pull/16221

From vromero at openjdk.org  Tue Oct 24 14:48:49 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 24 Oct 2023 14:48:49 GMT
Subject: Integrated: 8318160: javac does not reject private method reference
 with type-variable receiver
In-Reply-To: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
References: <mDrqLHGyfBeiF2UKjYFfXmUvcy7oeXwnTdFqyEFVnE8=.d64126d0-20ed-4262-9a55-384cdd3b08f2@github.com>
Message-ID: <BE6tlr9zSpphEToVLJHppFpHoj8UZM3xg3v1bvxwmnM=.e7cf9978-1308-4224-ab8b-ea568d73c787@github.com>

On Tue, 17 Oct 2023 00:19:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review this PR which is fixing a long standing regression in javac. Basically javac is accepting code like:
> 
> 
> import java.util.function.*;
> 
> class Test {
>     private String asString() {
>         return "bar";
>     }
> 
>     static <T extends Test> Function<T, String> foo() {
>         return T::asString;
>     }
> }
> 
> 
> this code should be rejected on the grounds that ::asString is a private method in class `Test` and thus not a member of type variable `T`
> 
> TIA

This pull request has now been integrated.

Changeset: e2720987
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e2720987b921b95fd8010cea60d2d6e436e5ebaa
Stats:     50 lines in 3 files changed: 50 ins; 0 del; 0 mod

8318160: javac does not reject private method reference with type-variable receiver

Reviewed-by: mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/16210

From cstein at openjdk.org  Tue Oct 24 15:46:52 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Oct 2023 15:46:52 GMT
Subject: RFR: 8307168: Inconsistent validation and handling of --system
 flag arguments [v2]
In-Reply-To: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
References: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
Message-ID: <s8cxLRBkqi7nMQ1z_PXHp__0hYt7cj_PLCaz8PCegYA=.022c8cd0-38c8-49e8-9c7b-4856e2af1ad7@github.com>

> Please review these changes that fix a bug in `javac`'s validation and handling of `--system` flag arguments.

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

  Added test cases and "unrolled" boolean expression

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16264/files
  - new: https://git.openjdk.org/jdk/pull/16264/files/190e200b..48d3c04e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16264&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16264&range=00-01

  Stats: 65 lines in 2 files changed: 52 ins; 4 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/16264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16264/head:pull/16264

PR: https://git.openjdk.org/jdk/pull/16264

From cstein at openjdk.org  Tue Oct 24 15:51:53 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 24 Oct 2023 15:51:53 GMT
Subject: RFR: 8307168: Inconsistent validation and handling of --system
 flag arguments [v3]
In-Reply-To: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
References: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
Message-ID: <9zuCnnFxZiXOrLUO1qqNAFHOURScvvDItCS42y2It7M=.a969d6ac-5a3b-44ab-8c32-f7f56b504d44@github.com>

> Please review these changes that fix a bug in `javac`'s validation and handling of `--system` flag arguments.

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

  Reverted change to internal `isCurrentPlatform` helper

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16264/files
  - new: https://git.openjdk.org/jdk/pull/16264/files/48d3c04e..b155a4e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16264&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16264&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16264/head:pull/16264

PR: https://git.openjdk.org/jdk/pull/16264

From vicente.romero at oracle.com  Tue Oct 24 17:24:35 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Tue, 24 Oct 2023 12:24:35 -0500
Subject: Regression: accessing a private method through a type variable
In-Reply-To: <a4a85d7f-e8df-4f3b-8a3e-b9f0bbe714d3@oracle.com>
References: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>
 <c1fbee53-765a-441e-92b3-d39b5709cb06@oracle.com>
 <a4a85d7f-e8df-4f3b-8a3e-b9f0bbe714d3@oracle.com>
Message-ID: <c547ef54-f436-4bb7-81b7-83f2fcf7cfbf@oracle.com>

Hi Remi,

Thanks again for the report, we have already fixed it, see [1] for more 
details,

Vicente

On 10/16/23 11:46, Vicente Romero wrote:
> Thanks for the report, we have created [1]. I'm taking a look at it,
>
> Vicente
>
> [1] https://bugs.openjdk.org/browse/JDK-8318160
>
> On 10/16/23 07:15, Maurizio Cimadamore wrote:
>>
>> I recall fixing this a long time ago:
>>
>>
>> https://bugs.openjdk.org/browse/JDK-6711619
>>
>>
>> Now, the test case mentioned in that bug is still correctly rejected 
>> by javac. Furhermore, a similar test:
>>
>>
>> ```
>> class X<E extends X<E>> {
>> ???????????? private static int m() { return 1; }
>> ???????????? int f() {
>> ???????????????????? return E.m();
>> ???????????? }
>> ??? }
>> ```
>>
>>
>> Also fails to compile with 21/22.
>>
>>
>> ```
>> Test.java:5: error: m() has private access in X
>> ???????????????????? return E.m();
>> ???????????????????????????? ^
>> 1 error
>>
>> ```
>>
>>
>> Trying to manipulate Remi's example, it seems the regression only has 
>> to do with method refreences whose receiver is a type variable.
>>
>>
>> Here's a minimal reproducer:
>>
>>
>> ```
>> import java.util.function.*;
>>
>> class Test {
>> ? private String asString() {
>> ??? return "bar";
>> ? }
>>
>> ? static <T extends Test> Function<T, String> foo() {
>> ??? return T::asString;
>> ? }
>> }
>> ```
>>
>> I filed a bug:
>>
>>
>> https://bugs.openjdk.org/browse/JDK-6711619
>>
>>
>> Thanks
>> Maurizio
>>
>>
>> On 16/10/2023 10:40, Sundararajan Athijegannathan wrote:
>>> fwiw, this compile from at least JDK 11 onwards:
>>>
>>> import java.util.*;
>>> import java.util.stream.*;
>>>
>>> public class TDotToString {
>>> ? class Bar {
>>> ? ? private String asString() {
>>> ? ? ? return "bar";
>>> ? ? }
>>> ? }
>>>
>>> ? static <T extends Bar> String foo(List<T> list) {
>>> ? ? return list.stream().map(T::asString).collect(Collectors.joining());
>>> ? }
>>> }
>>>
>>> javac from 1.8.0 does issue error as mentioned by Remi.
>>>
>>>
>>> -Sundar
>>> ------------------------------------------------------------------------
>>> *From:* compiler-dev <compiler-dev-retn at openjdk.org> on behalf of 
>>> Remi Forax <forax at univ-mlv.fr>
>>> *Sent:* 16 October 2023 13:57
>>> *To:* compiler-dev <compiler-dev at openjdk.org>
>>> *Subject:* Regression: accessing a private method through a type 
>>> variable
>>> Hello,
>>> There is a regression in recent versions of javac.
>>> javac 21 allows to access a private method through a type variable, 
>>> here T::asString.
>>>
>>> public class TDotToString {
>>> ? class Bar() {
>>> ??? private String asString() {
>>> ????? return "bar";
>>> ??? }
>>> ? }
>>>
>>> ? static <T extends Bar> String foo(List<T> list) {
>>> ??? return list.stream().map(T::asString).collect(Collectors.joining());
>>> ? }
>>> }
>>>
>>> Both IntelliJ and Eclipse emit an error in this case.
>>>
>>> And javac 8 emits
>>> ? TDotToString.java:12: error: invalid method reference
>>> ??? return list.stream().map(T::asString).collect(Collectors.joining());
>>> ???????????????????????????? ^
>>> ? cannot find symbol
>>> ??? symbol:?? method asString()
>>> ??? location: bound of type variable T
>>> ? where T is a type-variable:
>>> ??? T extends TDotToString.Bar declared in method <T>foo(List<T>)
>>> 1 error
>>>
>>> regards,
>>> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231024/72dc6b62/attachment-0001.htm>

From yuriy.maslyanko at oracle.com  Tue Oct 24 19:57:39 2023
From: yuriy.maslyanko at oracle.com (Yuriy Maslyanko)
Date: Tue, 24 Oct 2023 19:57:39 +0000
Subject: JEP 455: Non-enhanced switch statements
In-Reply-To: <SJ0PR10MB5648E7E3FD03BD77724DD3B282D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>
References: <SJ0PR10MB5648E7E3FD03BD77724DD3B282D5A@SJ0PR10MB5648.namprd10.prod.outlook.com>
Message-ID: <SJ0PR10MB56488C33C31E1948C955437C82DFA@SJ0PR10MB5648.namprd10.prod.outlook.com>

Hi Angelos,

Section 14.11.2 of https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html#jls-14.11.2 has this note:

For compatibility reasons, switch statements that are not enhanced switch statements are not required to be exhaustive.

Noticed that if the switch selector statement is float/double/boolean (in this case it's a non-enhanced switch statement), the code shown below fails with "error: the switch statement does not cover all possible input values":

    static boolean check = false;
    public static boolean testMethod() {
        double v1 = 1d;
        switch ( v1 ) {
            case 1d:
                check = true;
                break;
        }
        return check;
    }

However, it works for char, byte, short, int. Maybe this is a bug? Tried it with https://mach5.us.oracle.com/mdash/buildIds/2023-10-18-2214011.angelos.bimpoudis.dev, with same result. Could you please check?

Thanks,
Yuriy


From: Yuriy Maslyanko
Sent: Wednesday, October 18, 2023 2:39 PM
To: Angelos Bimpoudis <angelos.bimpoudis at oracle.com>
Cc: compiler-dev at openjdk.org
Subject: JEP 455: JLS change for switch expressions

Hi Angelos,

JCK team started working on JEP 455: Primitive types in Patterns, instanceof, and switch (Preview). Just noticed that in the draft spec, https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html, there is a change for the switch statement:

14.11 The switch Statement
The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-14.11-200)
->
The Expression is called the selector expression. The type of the selector expression can be either a primitive or a reference type.

But the corresponding assertion for switch expressions is not changed:

15.28. switch Expressions
The Expression is called the selector expression. The type of the selector expression must be char, byte, short, int, or a reference type, or a compile-time error occurs. (jls-15.28-200)

Could you please take a look?

Thanks,
Yuriy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231024/c509e7f3/attachment.htm>

From forax at univ-mlv.fr  Tue Oct 24 20:20:42 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 24 Oct 2023 22:20:42 +0200 (CEST)
Subject: Regression: accessing a private method through a type variable
In-Reply-To: <c547ef54-f436-4bb7-81b7-83f2fcf7cfbf@oracle.com>
References: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>
 <c1fbee53-765a-441e-92b3-d39b5709cb06@oracle.com>
 <a4a85d7f-e8df-4f3b-8a3e-b9f0bbe714d3@oracle.com>
 <c547ef54-f436-4bb7-81b7-83f2fcf7cfbf@oracle.com>
Message-ID: <706701775.34009775.1698178842416.JavaMail.zimbra@univ-eiffel.fr>

> From: "Vicente Romero" <vicente.romero at oracle.com>
> To: "Maurizio Cimadamore" <maurizio.cimadamore at oracle.com>,
> "SUNDARARAJAN.ATHIJEGANNATHAN" <sundararajan.athijegannathan at oracle.com>, "Remi
> Forax" <forax at univ-mlv.fr>, "compiler-dev" <compiler-dev at openjdk.org>
> Sent: Tuesday, October 24, 2023 7:24:35 PM
> Subject: Re: Regression: accessing a private method through a type variable

> Hi Remi,

> Thanks again for the report, we have already fixed it, see [1] for more details,

> Vicente
Hello Vincente, 
thanks for fixing that issue, for the anecdote, this issue was found doing mob programming [1] with my students. 
I think next week, we will study how the regression was introduced and and how you and Maurizio fix it :) 

R?mi 
[1] https://en.wikipedia.org/wiki/Team_programming#Mob_programming 

> On 10/16/23 11:46, Vicente Romero wrote:

>> Thanks for the report, we have created [1]. I'm taking a look at it,

>> Vicente

>> [1] [ https://bugs.openjdk.org/browse/JDK-8318160 |
>> https://bugs.openjdk.org/browse/JDK-8318160 ]

>> On 10/16/23 07:15, Maurizio Cimadamore wrote:

>>> I recall fixing this a long time ago:

>>> [ https://bugs.openjdk.org/browse/JDK-6711619 |
>>> https://bugs.openjdk.org/browse/JDK-6711619 ]

>>> Now, the test case mentioned in that bug is still correctly rejected by javac.
>>> Furhermore, a similar test:

>>> ```
>>> class X<E extends X<E>> {
>>> private static int m() { return 1; }
>>> int f() {
>>> return E.m();
>>> }
>>> }
>>> ```

>>> Also fails to compile with 21/22.

>>> ```
>>> Test.java:5: error: m() has private access in X
>>> return E.m();
>>> ^
>>> 1 error

>>> ```

>>> Trying to manipulate Remi's example, it seems the regression only has to do with
>>> method refreences whose receiver is a type variable.

>>> Here's a minimal reproducer:

>>> ```
>>> import java.util.function.*;

>>> class Test {
>>> private String asString() {
>>> return "bar";
>>> }

>>> static <T extends Test> Function<T, String> foo() {
>>> return T::asString;
>>> }
>>> }
>>> ```

>>> I filed a bug:

>>> [ https://bugs.openjdk.org/browse/JDK-6711619 |
>>> https://bugs.openjdk.org/browse/JDK-6711619 ]

>>> Thanks
>>> Maurizio

>>> On 16/10/2023 10:40, Sundararajan Athijegannathan wrote:

>>>> fwiw, this compile from at least JDK 11 onwards:

>>>> import java.util.*;
>>>> import java.util.stream.*;

>>>> public class TDotToString {
>>>> class Bar {
>>>> private String asString() {
>>>> return "bar";
>>>> }
>>>> }

>>>> static <T extends Bar> String foo(List<T> list) {
>>>> return list.stream().map(T::asString).collect(Collectors.joining());
>>>> }
>>>> }

>>>> javac from 1.8.0 does issue error as mentioned by Remi.

>>>> -Sundar

>>>> From: compiler-dev [ mailto:compiler-dev-retn at openjdk.org |
>>>> <compiler-dev-retn at openjdk.org> ] on behalf of Remi Forax [
>>>> mailto:forax at univ-mlv.fr | <forax at univ-mlv.fr> ]
>>>> Sent: 16 October 2023 13:57
>>>> To: compiler-dev [ mailto:compiler-dev at openjdk.org | <compiler-dev at openjdk.org>
>>>> ]
>>>> Subject: Regression: accessing a private method through a type variable
>>>> Hello,
>>>> There is a regression in recent versions of javac.
>>>> javac 21 allows to access a private method through a type variable, here
>>>> T::asString.

>>>> public class TDotToString {
>>>> class Bar() {
>>>> private String asString() {
>>>> return "bar";
>>>> }
>>>> }

>>>> static <T extends Bar> String foo(List<T> list) {
>>>> return list.stream().map(T::asString).collect(Collectors.joining());
>>>> }
>>>> }

>>>> Both IntelliJ and Eclipse emit an error in this case.

>>>> And javac 8 emits
>>>> TDotToString.java:12: error: invalid method reference
>>>> return list.stream().map(T::asString).collect(Collectors.joining());
>>>> ^
>>>> cannot find symbol
>>>> symbol: method asString()
>>>> location: bound of type variable T
>>>> where T is a type-variable:
>>>> T extends TDotToString.Bar declared in method <T>foo(List<T>)
>>>> 1 error

>>>> regards,
>>>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231024/6cd94e0d/attachment-0001.htm>

From cstein at openjdk.org  Wed Oct 25 06:11:52 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 25 Oct 2023 06:11:52 GMT
Subject: RFR: 8307168: Inconsistent validation and handling of --system
 flag arguments [v4]
In-Reply-To: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
References: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
Message-ID: <vAUPj-43Mh91uZt4aZUPP6KOpwrxWoY6oFceBQVd16s=.d9e52de9-61b4-4128-9bf2-541ee9bdf84b@github.com>

> Please review these changes that fix a bug in `javac`'s validation and handling of `--system` flag arguments.

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

  Update OptionSmokeTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16264/files
  - new: https://git.openjdk.org/jdk/pull/16264/files/b155a4e4..73e7f0e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16264&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16264&range=02-03

  Stats: 18 lines in 1 file changed: 0 ins; 17 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16264/head:pull/16264

PR: https://git.openjdk.org/jdk/pull/16264

From cstein at openjdk.org  Wed Oct 25 10:50:28 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 25 Oct 2023 10:50:28 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v3]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <rcaoerm1saVVyGlPWFd2o-C3HAUW7txCE_khcDVPngE=.b502aaab-515c-4f0f-befc-0f9234f11478@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

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

  Add support for launching a public class
  
  If the first class declared in the initial file
  does not have a main entry point, check if the
  file has a public top-level class with a name
  matching the name of the file and with a main
  entry point. If there is one, invoke the main
  entry point of that class, otherwise fail.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/093ab1ce..f96772c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=01-02

  Stats: 74 lines in 3 files changed: 46 ins; 8 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/13712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13712/head:pull/13712

PR: https://git.openjdk.org/jdk/pull/13712

From cstein at openjdk.org  Wed Oct 25 11:02:41 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 25 Oct 2023 11:02:41 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
Message-ID: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>

> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
> 
> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
> 
> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
> 
> ### Open Ends
> 
> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
> 
> ### OpenJDK's Demo Programs
> 
> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
> 
> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`

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

  Main method determines the main class now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13712/files
  - new: https://git.openjdk.org/jdk/pull/13712/files/f96772c9..854d9991

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13712&range=02-03

  Stats: 12 lines in 1 file changed: 5 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13712.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13712/head:pull/13712

PR: https://git.openjdk.org/jdk/pull/13712

From alanb at openjdk.org  Wed Oct 25 13:38:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Oct 2023 13:38:41 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
Message-ID: <Q-_KHeDaVulTBe7ZJj-L_jGoQShRkitQfQqmnK3pWiE=.9660633f-1fd1-4cc3-a893-68715e8d372a@github.com>

On Wed, 25 Oct 2023 11:02:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
>> 
>> ### OpenJDK's Demo Programs
>> 
>> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
>> 
>> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
>> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
>> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
>> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
>> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
>> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
>> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
>> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
>> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
>> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
>> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Main method determines the main class now

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 227:

> 225:         var modulePathModules = modulePathFinder.findAll().stream().map(ModuleReference::descriptor).map(ModuleDescriptor::name).toList();
> 226:         if (!modulePathModules.isEmpty()) {
> 227:             var modulePathConfiguration = bootLayer.configuration().resolveAndBind(modulePathFinder, ModuleFinder.of(), Set.copyOf(modulePathModules));

Some (or all) of the modules on the applications module path may be in the boot layer, I don't think you want to have another instance of these modules in the child layer. So I think check this line, it looks the first two parameters needs to be swapped so that only modules not found in the boot layer will be resolved.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 228:

> 226:         if (!modulePathModules.isEmpty()) {
> 227:             var modulePathConfiguration = bootLayer.configuration().resolveAndBind(modulePathFinder, ModuleFinder.of(), Set.copyOf(modulePathModules));
> 228:             var modulePathLayer = ModuleLayer.defineModulesWithOneLoader(modulePathConfiguration, List.of(bootLayer), parent).layer();

Since you don't need the Controller then it may be simpler to use just `bootLayer.defineModulesWithOneLoader(modulePathConfiguration, parent);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1371772651
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1371776334

From alanb at openjdk.org  Wed Oct 25 13:46:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Oct 2023 13:46:38 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
Message-ID: <lt2hx3lOAsl5FkVoaPOoBt2Q0xv4wiAhHtU5e5oLcwk=.ed13369f-2b3f-4d51-b688-1ba2558b114f@github.com>

On Wed, 25 Oct 2023 11:02:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
>> 
>> ### OpenJDK's Demo Programs
>> 
>> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
>> 
>> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
>> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
>> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
>> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
>> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
>> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
>> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
>> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
>> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
>> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
>> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Main method determines the main class now

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 238:

> 236:         var memoryConfig = parentLayer.configuration().resolveAndBind(memoryFinder, ModuleFinder.of(), Set.of(applicationModule.name()));
> 237:         var memoryClassLoader = new MemoryClassLoader(inMemoryClasses, parentLoader, applicationModule, descriptor, this::compileJavaFileByName);
> 238:         var memoryController = ModuleLayer.defineModules(memoryConfig, List.of(parentLayer), __ -> memoryClassLoader);

It would be helpful if the comment were expanded to explain why memoryClassLoader is needed here. ClassLoaders created by the defineModulesXXX methods are capable to loading modules in memory file systems, the issue is the dynamic compilation (I think).

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 246:

> 244:         memoryController.addOpens(module, mainClassNamePackageName, getClass().getModule());
> 245: 
> 246:         return memoryLayer.findLoader(applicationModule.name()).loadClass(mainClassName);

The defining class loader for the main class will be memoryClassLoader, right?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1371789699
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1371785140

From alanb at openjdk.org  Wed Oct 25 13:55:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 25 Oct 2023 13:55:38 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
Message-ID: <n0hAa8MLwqNJCkMnsODXuTzIShizA1RzFkmlhqKbXg0=.dd0af9af-6f29-4bab-95cf-b91e6df0bb24@github.com>

On Wed, 25 Oct 2023 11:02:41 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change set implementing [JEP 458](https://openjdk.org/jeps/458) "Launch Multi-File Source-Code Programs" by introducing a new entry-point `SourceLauncher` in package `com.sun.tools.javac.launcher` of module `jdk.compiler`. The former `Main` entry-point is kept as-is in order to preserve (and possibly fall back to) existing behaviour of launching single-file source-code programs.
>> 
>> The code of the new entry-point and other new classes introduced by this pull request is based on the original implementation. It extends it to dynamically resolve required types "on-the-fly" using an in-memory class loader capable to compile Java source files - applying a strict name-based pattern as described in the JEP.
>> 
>> To support modular programs with user-provided additional modules (launched for example via `java -p . pkg/Prog1.java`) `ALL-MODULE-PATH` is now also part of the implicit list of modules name in source launch mode.
>> 
>> ### Open Ends
>> 
>> - [ ] Tests with [JEP ?: Implicitly Declared Classes and Instance Main Method (2nd Preview)](https://bugs.openjdk.org/browse/JDK-8315398)
>> 
>> ### OpenJDK's Demo Programs
>> 
>> OpenJDK's demo programs can be found in the [src/demo/share/jfc](https://github.com/openjdk/jdk/tree/master/src/demo/share/jfc) directory. These multi-file source-code programs can be launched via `java ${PROGRAM}` once this implementation is integrated; with `${PROGRAM}` being one of the following files:
>> 
>> - [x] `src/demo/share/jfc/CodePointIM/CodePointIM.java`
>> - [x] `src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java`
>> - [x] `src/demo/share/jfc/Font2DTest/Font2DTest.java`
>> - [x] `src/demo/share/jfc/J2Ddemo/java2d/J2Ddemo.java`
>> - [x] `src/demo/share/jfc/Metalworks/Metalworks.java`
>> - [x] `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SampleTree/SampleTree.java`
>> - [ ] `src/demo/share/jfc/Stylepad/Stylepad.java` ? requires `src/demo/share/jfc/Notepad/Notepad.java`
>> - [x] `src/demo/share/jfc/SwingSet2/SwingSet2.java`
>> - [ ] `src/demo/share/jfc/TableExample/TableExample.java` ? requires a database driver on the class path
>> - [ ] `src/demo/share/jfc/TableExample/TableExample2.java` ?  requires a database driver on the class path
>> - [x] `src/demo/share/jfc/TableExample/TableExample3.java`
>> - [x] `src/demo/share/jfc/TableExample/TableExample4.java`
>> - [x] `src/demo/share/jfc/TransparentRuler/transparentruler/Ruler.java`
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Main method determines the main class now

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryModuleFinder.java line 48:

> 46: import java.util.stream.Stream;
> 47: 
> 48: import jdk.internal.module.Resources;

This is related to robustness/security so probably okay to have javac use it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1371803231

From asotona at openjdk.org  Wed Oct 25 16:53:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 25 Oct 2023 16:53:22 GMT
Subject: RFR: 8308753: Class-File API transition to Preview [v23]
In-Reply-To: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
Message-ID: <2HPq6LjW9J4vSEMb6aP4QWrtNJ607vVa-Rw1PyeD4u4=.7f1159bc-c11a-46b4-8825-7fb251d4c904@github.com>

> Classfile API is an internal library under package `jdk.internal.classfile`?in JDK 21.
> This pull request turns the Classfile API into a preview feature and moves it into `java.lang.classfile`.
> It repackages all uses across JDK and tests and adds lots of missing Javadoc.
> 
> This PR goes in sync with?[JDK-8308754](https://bugs.openjdk.org/browse/JDK-8308754): Class-File API (Preview) (CSR)
> and?[JDK-8280389](https://bugs.openjdk.org/browse/JDK-8280389): Class-File API (Preview) (JEP).
> 
> Online javadoc is available at:?
> https://cr.openjdk.org/~asotona/JDK-8308753-preview/api/java.base/java/lang/classfile/package-summary.html
> 
> In addition to the primary transition to preview, this pull request also includes:
> - All?Classfile*?classes ranamed to?ClassFile*?(based on JEP discussion).
> - A new preview feature, `CLASSFILE_API`, has been added.
> - Buildsystem tool required a little patch to support annotated modules.
> - All JDK modules using the Classfile API are newly participating in the preview.
> - All tests that use the Classfile API now have preview enabled.
> - A few Javac tests not allowing preview have been partially reverted; their conversion can be re-applied when the Classfile API leaves preview mode.
> 
> Despite the number of affected files, this pull request is relatively straight-forward. The preview version of the Classfile API is based on the internal version of the library from the JDK master branch, and there are no API features added.
> 
> Please review this pull request to help the Classfile API turn into a preview.
> 
> Any comments are welcome.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 357 commits:

 - fixed jdk.jfr
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - applied javadoc fix suggestions
 - fixed new benchmark
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java
 - removed trailing space
 - Merge branch 'master' into JDK-8308753-preview
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - package info javadoc improvements
 - removed obsolete exports from BuildMicrobenchmark.gmk
 - Merge branch 'master' into JDK-8308753-preview
 - ... and 347 more: https://git.openjdk.org/jdk/compare/9e98ee67...0587f208

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

Changes: https://git.openjdk.org/jdk/pull/15706/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15706&range=22
  Stats: 32165 lines in 768 files changed: 14622 ins; 14054 del; 3489 mod
  Patch: https://git.openjdk.org/jdk/pull/15706.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15706/head:pull/15706

PR: https://git.openjdk.org/jdk/pull/15706

From mcimadamore at openjdk.org  Wed Oct 25 17:45:45 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Oct 2023 17:45:45 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
Message-ID: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>

This PR fixes how javac loads dynamic variable symbols in `Gen` - currently, either a `ldc` or `ldc_w` is emitted. This is problematic, as, depending on the type of the dynamic constant, in some cases `ldc2_w` might be required (e.g. if the type of the constant is either `long` or `double`).

I've updated the existing compiler condy test to check which `ldc` opcode is emitted for the various constants. I've also verified that the updated test fails w/o the changes in this patch.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/16367/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16367&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318837
  Stats: 35 lines in 3 files changed: 23 ins; 1 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/16367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16367/head:pull/16367

PR: https://git.openjdk.org/jdk/pull/16367

From vromero at openjdk.org  Wed Oct 25 18:13:34 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 25 Oct 2023 18:13:34 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
In-Reply-To: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
Message-ID: <kJAPdD6XYfLAUxoUIuuxbIrjVABFPzv-HN3DIufIZvw=.16cbc60f-ca1e-47f0-bac6-b9023fd049db@github.com>

On Wed, 25 Oct 2023 17:39:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes how javac loads dynamic variable symbols in `Gen` - currently, either a `ldc` or `ldc_w` is emitted. This is problematic, as, depending on the type of the dynamic constant, in some cases `ldc2_w` might be required (e.g. if the type of the constant is either `long` or `double`).
> 
> I've updated the existing compiler condy test to check which `ldc` opcode is emitted for the various constants. I've also verified that the updated test fails w/o the changes in this patch.

looks good

side: given that you are in the neighborhood :) does it make sense to fold the cases for: `ldc2w` and `ldc2` at: `Code::emitop2`?

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16367#pullrequestreview-1697963249
PR Comment: https://git.openjdk.org/jdk/pull/16367#issuecomment-1779800622

From duke at openjdk.org  Wed Oct 25 23:29:42 2023
From: duke at openjdk.org (Josiah Noel)
Date: Wed, 25 Oct 2023 23:29:42 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
Message-ID: <Bh2E5JDkTcJhYAFH8lWllkjU9Q3BeKvtyEhf1dVpCU8=.54e720fe-033e-4f02-8c4a-b5a5a223c50c@github.com>

On Fri, 6 Oct 2023 21:55:30 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Change annotation processing to be opt-in rather than opt-out.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos.

Just out of curiosity though, why didn't this (pretty sizable breaking change) get a JEP? The dynamic agents being disabled by default got one.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1780192223

From mcimadamore at openjdk.org  Wed Oct 25 23:52:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 25 Oct 2023 23:52:41 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
In-Reply-To: <kJAPdD6XYfLAUxoUIuuxbIrjVABFPzv-HN3DIufIZvw=.16cbc60f-ca1e-47f0-bac6-b9023fd049db@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
 <kJAPdD6XYfLAUxoUIuuxbIrjVABFPzv-HN3DIufIZvw=.16cbc60f-ca1e-47f0-bac6-b9023fd049db@github.com>
Message-ID: <njxuzjhxl-RQhPSoJYwXVy49VQULBTymMNCTHSXF2Sg=.720dae91-e8f8-45f7-82ef-73ae22e29ed2@github.com>

On Wed, 25 Oct 2023 18:10:40 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> side: given that you are in the neighborhood :) does it make sense to fold the cases for: `ldc2w` and `ldc2` at: `Code::emitop2`?

I can - but, I realized when I wrote the patch that the naming of the constants is wrong. The JVMS only knows about these instructions:

* [ldc](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.html#jvms-6.5.ldc)
* [ldc_w](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.html#jvms-6.5.ldc_w)
* [ldc2_w](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.html#jvms-6.5.ldc2_w)

While javac has `ldc`, `ldc2` and `ldc2_w`. So, I suspect javac's `ldc2` is really `ldc_w`. Should this be renamed too?

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

PR Comment: https://git.openjdk.org/jdk/pull/16367#issuecomment-1780208754

From darcy at openjdk.org  Thu Oct 26 00:32:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Oct 2023 00:32:42 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <Bh2E5JDkTcJhYAFH8lWllkjU9Q3BeKvtyEhf1dVpCU8=.54e720fe-033e-4f02-8c4a-b5a5a223c50c@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <Bh2E5JDkTcJhYAFH8lWllkjU9Q3BeKvtyEhf1dVpCU8=.54e720fe-033e-4f02-8c4a-b5a5a223c50c@github.com>
Message-ID: <7AZJ2h8t-7ZCSTPvPNYpqj_GtG1vjsbVJO5HSpIXwHg=.cb84a0a8-8a13-4987-9bf4-84b12fabb614@github.com>

On Wed, 25 Oct 2023 23:26:36 GMT, Josiah Noel <duke at openjdk.org> wrote:

> Just out of curiosity though, why didn't this (pretty sizable breaking change) get a JEP? The dynamic agents being disabled by default got one.

The short answer is despite the Sturm und Drang of any discussions on Reddit, I don't agree with the assessment that this PR constitutes a "pretty sizable breaking change."

To summarize: the capabilities of javac with respect to annotation processing are not changing in any way. The only aspect that is changing is what is the default policy if no explicit annotation processing configuration options are given.

If a build environment is already using any of the javac options `-processor`, `--processor-path`, `--processor-module-path`, or `-proc:only` nothing changes.

If a build environment does not have annotation processors on the class path, nothing changes.

In JDK 21, javac prints a note -- not a warning for a reason I'll explain below -- to identify the situations where implicit annotation processing is being relied on. Now it is true that users might not see this note, but communication about the JDK 21 change was publicized on the quality-discuss list to help make sure interested parties were informed of the change. The reason the javac message is a note and not a warning is so that build environments running under `-Werror` will not (spuriously) fail solely due to communicating the possibility of a future policy change.

Starting in JDK 21, a build environment or other javac invocation can be explicitly configured to request the old default policy by using `-proc:full`. All the other existing annotation processing configuration options (`-processor`, `-processor-path`, ...) are still supported and mean exactly the same thing as before.

Only in JDK 22 will the default policy actually be change to _not_ look on the class path for annotation processors (unless `-proc:full` is also given). However, there need not be any flag day for changing to JDK 22 specifically since the option to request the old policy is accepted in JDK 21.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1780236896

From vromero at openjdk.org  Thu Oct 26 03:23:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 26 Oct 2023 03:23:29 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
In-Reply-To: <njxuzjhxl-RQhPSoJYwXVy49VQULBTymMNCTHSXF2Sg=.720dae91-e8f8-45f7-82ef-73ae22e29ed2@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
 <kJAPdD6XYfLAUxoUIuuxbIrjVABFPzv-HN3DIufIZvw=.16cbc60f-ca1e-47f0-bac6-b9023fd049db@github.com>
 <njxuzjhxl-RQhPSoJYwXVy49VQULBTymMNCTHSXF2Sg=.720dae91-e8f8-45f7-82ef-73ae22e29ed2@github.com>
Message-ID: <_RZPWG57R7qU8P4StCXQvqkjcGxsvkwlsm0IuwuPW_k=.79361f31-ef40-44bb-96c0-2ef20f6a1ad9@github.com>

On Wed, 25 Oct 2023 23:49:45 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > side: given that you are in the neighborhood :) does it make sense to fold the cases for: `ldc2w` and `ldc2` at: `Code::emitop2`?
> 
> I can - but, I realized when I wrote the patch that the naming of the constants is wrong. The JVMS only knows about these instructions:
> 
>     * [ldc](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.html#jvms-6.5.ldc)
> 
>     * [ldc_w](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.html#jvms-6.5.ldc_w)
> 
>     * [ldc2_w](https://docs.oracle.com/javase/specs/jvms/se21/html/jvms-6.html#jvms-6.5.ldc2_w)
> 
> 
> While javac has `ldc`, `ldc2` and `ldc2_w`. So, I suspect javac's `ldc2` is really `ldc_w`. Should this be renamed too?

as you please but then you probably should also rename `ldc1` to plain `ldc`

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

PR Comment: https://git.openjdk.org/jdk/pull/16367#issuecomment-1780352724

From duke at openjdk.org  Thu Oct 26 03:24:47 2023
From: duke at openjdk.org (Rob Bygrave)
Date: Thu, 26 Oct 2023 03:24:47 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <7AZJ2h8t-7ZCSTPvPNYpqj_GtG1vjsbVJO5HSpIXwHg=.cb84a0a8-8a13-4987-9bf4-84b12fabb614@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <Bh2E5JDkTcJhYAFH8lWllkjU9Q3BeKvtyEhf1dVpCU8=.54e720fe-033e-4f02-8c4a-b5a5a223c50c@github.com>
 <7AZJ2h8t-7ZCSTPvPNYpqj_GtG1vjsbVJO5HSpIXwHg=.cb84a0a8-8a13-4987-9bf4-84b12fabb614@github.com>
Message-ID: <_wWk94od4ReNUx9KM1vOWlWcnw9Q_pO6Wdns-FDleL4=.cf37d33e-32c9-40f5-8f82-5a5443714904@github.com>

On Thu, 26 Oct 2023 00:29:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> there need not be any flag day for changing to JDK 22 specifically since the option to request the old policy is accepted in JDK 21

Just to say, most of our libs build against **11, 17, 21 and EA/22**. So for this reason our projects we can't trivially make use of `-proc:full` introduced in 21 as that fails the builds using 11 and 17 and instead we needed to introduce build profiles for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1780353758

From vicente.romero at oracle.com  Thu Oct 26 04:57:51 2023
From: vicente.romero at oracle.com (Vicente Romero)
Date: Wed, 25 Oct 2023 23:57:51 -0500
Subject: [External] : Re: Regression: accessing a private method through a
 type variable
In-Reply-To: <706701775.34009775.1698178842416.JavaMail.zimbra@univ-eiffel.fr>
References: <197249845.25132301.1697444851214.JavaMail.zimbra@univ-eiffel.fr>
 <DM6PR10MB29541241C314FCEEA2C7B32FEAD7A@DM6PR10MB2954.namprd10.prod.outlook.com>
 <c1fbee53-765a-441e-92b3-d39b5709cb06@oracle.com>
 <a4a85d7f-e8df-4f3b-8a3e-b9f0bbe714d3@oracle.com>
 <c547ef54-f436-4bb7-81b7-83f2fcf7cfbf@oracle.com>
 <706701775.34009775.1698178842416.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <6a2bc47e-618c-4337-af85-964b253c3247@oracle.com>

Hi Remi,

> Hello Vincente,
> thanks for fixing that issue, for the anecdote, this issue was found 
> doing mob programming [1] with my students.

interesting :)

> I think next week, we will study how the regression was introduced and 
> and how you and Maurizio fix it :)

:) this could be considered as software archeology

>
> R?mi
> [1] https://en.wikipedia.org/wiki/Team_programming#Mob_programming 
> <https://urldefense.com/v3/__https://en.wikipedia.org/wiki/Team_programming*Mob_programming__;Iw!!ACWV5N9M2RV99hQ!IqPY8L_FXrpGemBiKCbKjreCUO-icqhonFtyho2_ZUbn2rwFvsK3tI_OePWXLwuRJkV5mOxpJJsji1wXT0y1Ww$>

Say hello to your students :),
Vicente

>
>
>
>     On 10/16/23 11:46, Vicente Romero wrote:
>
>         Thanks for the report, we have created [1]. I'm taking a look
>         at it,
>
>         Vicente
>
>         [1] https://bugs.openjdk.org/browse/JDK-8318160
>
>         On 10/16/23 07:15, Maurizio Cimadamore wrote:
>
>             I recall fixing this a long time ago:
>
>
>             https://bugs.openjdk.org/browse/JDK-6711619
>
>
>             Now, the test case mentioned in that bug is still
>             correctly rejected by javac. Furhermore, a similar test:
>
>
>             ```
>             class X<E extends X<E>> {
>             ???????????? private static int m() { return 1; }
>             ???????????? int f() {
>             ???????????????????? return E.m();
>             ???????????? }
>             ??? }
>             ```
>
>
>             Also fails to compile with 21/22.
>
>
>             ```
>             Test.java:5: error: m() has private access in X
>             ???????????????????? return E.m();
>             ???????????????????????????? ^
>             1 error
>
>             ```
>
>
>             Trying to manipulate Remi's example, it seems the
>             regression only has to do with method refreences whose
>             receiver is a type variable.
>
>
>             Here's a minimal reproducer:
>
>
>             ```
>             import java.util.function.*;
>
>             class Test {
>             ? private String asString() {
>             ??? return "bar";
>             ? }
>
>             ? static <T extends Test> Function<T, String> foo() {
>             ??? return T::asString;
>             ? }
>             }
>             ```
>
>             I filed a bug:
>
>
>             https://bugs.openjdk.org/browse/JDK-6711619
>
>
>             Thanks
>             Maurizio
>
>
>             On 16/10/2023 10:40, Sundararajan Athijegannathan wrote:
>
>                 fwiw, this compile from at least JDK 11 onwards:
>
>                 import java.util.*;
>                 import java.util.stream.*;
>
>                 public class TDotToString {
>                 ? class Bar {
>                 ? ? private String asString() {
>                 ? ? ? return "bar";
>                 ? ? }
>                 ? }
>
>                 ? static <T extends Bar> String foo(List<T> list) {
>                 ? ? return
>                 list.stream().map(T::asString).collect(Collectors.joining());
>                 ? }
>                 }
>
>                 javac from 1.8.0 does issue error as mentioned by Remi.
>
>
>                 -Sundar
>                 ------------------------------------------------------------------------
>                 *From:* compiler-dev <compiler-dev-retn at openjdk.org>
>                 on behalf of Remi Forax <forax at univ-mlv.fr>
>                 *Sent:* 16 October 2023 13:57
>                 *To:* compiler-dev <compiler-dev at openjdk.org>
>                 *Subject:* Regression: accessing a private method
>                 through a type variable
>                 Hello,
>                 There is a regression in recent versions of javac.
>                 javac 21 allows to access a private method through a
>                 type variable, here T::asString.
>
>                 public class TDotToString {
>                 ? class Bar() {
>                 ??? private String asString() {
>                 ????? return "bar";
>                 ??? }
>                 ? }
>
>                 ? static <T extends Bar> String foo(List<T> list) {
>                 ??? return
>                 list.stream().map(T::asString).collect(Collectors.joining());
>                 ? }
>                 }
>
>                 Both IntelliJ and Eclipse emit an error in this case.
>
>                 And javac 8 emits
>                 ? TDotToString.java:12: error: invalid method reference
>                 ??? return
>                 list.stream().map(T::asString).collect(Collectors.joining());
>                 ???????????????????????????? ^
>                 ? cannot find symbol
>                 ??? symbol:?? method asString()
>                 ??? location: bound of type variable T
>                 ? where T is a type-variable:
>                 ??? T extends TDotToString.Bar declared in method
>                 <T>foo(List<T>)
>                 1 error
>
>                 regards,
>                 R?mi
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231025/4275d5a2/attachment-0001.htm>

From mcimadamore at openjdk.org  Thu Oct 26 10:14:06 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Oct 2023 10:14:06 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads [v2]
In-Reply-To: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
Message-ID: <tcy8P9A51vsKNKkWnYzhT5cy4kap7eZl0y_dPFDuWj4=.84c5823a-4baa-4ccd-9852-9589aca01bcd@github.com>

> This PR fixes how javac loads dynamic variable symbols in `Gen` - currently, either a `ldc` or `ldc_w` is emitted. This is problematic, as, depending on the type of the dynamic constant, in some cases `ldc2_w` might be required (e.g. if the type of the constant is either `long` or `double`).
> 
> I've updated the existing compiler condy test to check which `ldc` opcode is emitted for the various constants. I've also verified that the updated test fails w/o the changes in this patch.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments
  Simplify code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16367/files
  - new: https://git.openjdk.org/jdk/pull/16367/files/23d4ef69..59c0bfe4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16367&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16367&range=00-01

  Stats: 23 lines in 2 files changed: 4 ins; 18 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16367/head:pull/16367

PR: https://git.openjdk.org/jdk/pull/16367

From mcimadamore at openjdk.org  Thu Oct 26 10:14:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Oct 2023 10:14:08 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
In-Reply-To: <_RZPWG57R7qU8P4StCXQvqkjcGxsvkwlsm0IuwuPW_k=.79361f31-ef40-44bb-96c0-2ef20f6a1ad9@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
 <kJAPdD6XYfLAUxoUIuuxbIrjVABFPzv-HN3DIufIZvw=.16cbc60f-ca1e-47f0-bac6-b9023fd049db@github.com>
 <njxuzjhxl-RQhPSoJYwXVy49VQULBTymMNCTHSXF2Sg=.720dae91-e8f8-45f7-82ef-73ae22e29ed2@github.com>
 <_RZPWG57R7qU8P4StCXQvqkjcGxsvkwlsm0IuwuPW_k=.79361f31-ef40-44bb-96c0-2ef20f6a1ad9@github.com>
Message-ID: <HHVHRgjTml-ygE9sBFUaaYpgI0eHTDpFrYcyLtMm7f4=.b979bb38-28e7-4b69-a6dc-a85e1500b3b6@github.com>

On Thu, 26 Oct 2023 03:19:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> > > side: given that you are in the neighborhood :) does it make sense to fold the cases for: `ldc2w` and `ldc2` at: `Code::emitop2`?

This turned out to be a very good suggestion, thanks! While doing it, I realized that we already had a method (`Types::constantType`) to get the `Type` of a constant, so the new method I added to `LoadableConstant` is not really required (and I have now removed it).

In the end I left the names as they are, beacuse, while confusing, when looking at `emitOp` they kind of make sense - e.g. 1/2 is used to denote the number of operand bytes. So at least it's self-consistent :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/16367#issuecomment-1780815901

From jlahoda at openjdk.org  Thu Oct 26 12:32:33 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 26 Oct 2023 12:32:33 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads [v2]
In-Reply-To: <tcy8P9A51vsKNKkWnYzhT5cy4kap7eZl0y_dPFDuWj4=.84c5823a-4baa-4ccd-9852-9589aca01bcd@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
 <tcy8P9A51vsKNKkWnYzhT5cy4kap7eZl0y_dPFDuWj4=.84c5823a-4baa-4ccd-9852-9589aca01bcd@github.com>
Message-ID: <WNfAnC98qj2wZZbZAcTWj_6KUyBsJ15xV4Vz2k9jQWs=.e006a938-fa5a-429a-a9f3-4611e7cd98f5@github.com>

On Thu, 26 Oct 2023 10:14:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This PR fixes how javac loads dynamic variable symbols in `Gen` - currently, either a `ldc` or `ldc_w` is emitted. This is problematic, as, depending on the type of the dynamic constant, in some cases `ldc2_w` might be required (e.g. if the type of the constant is either `long` or `double`).
>> 
>> I've updated the existing compiler condy test to check which `ldc` opcode is emitted for the various constants. I've also verified that the updated test fails w/o the changes in this patch.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments
>   Simplify code

Looks good to me.

I wonder if we should also simplify `Items.ImmediateItem.ldc`, since now `Code.emitLdc` handles the long/double on its own?

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16367#pullrequestreview-1699506876

From vromero at openjdk.org  Thu Oct 26 13:14:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 26 Oct 2023 13:14:31 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
In-Reply-To: <HHVHRgjTml-ygE9sBFUaaYpgI0eHTDpFrYcyLtMm7f4=.b979bb38-28e7-4b69-a6dc-a85e1500b3b6@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
 <kJAPdD6XYfLAUxoUIuuxbIrjVABFPzv-HN3DIufIZvw=.16cbc60f-ca1e-47f0-bac6-b9023fd049db@github.com>
 <njxuzjhxl-RQhPSoJYwXVy49VQULBTymMNCTHSXF2Sg=.720dae91-e8f8-45f7-82ef-73ae22e29ed2@github.com>
 <_RZPWG57R7qU8P4StCXQvqkjcGxsvkwlsm0IuwuPW_k=.79361f31-ef40-44bb-96c0-2ef20f6a1ad9@github.com>
 <HHVHRgjTml-ygE9sBFUaaYpgI0eHTDpFrYcyLtMm7f4=.b979bb38-28e7-4b69-a6dc-a85e1500b3b6@github.com>
Message-ID: <8uk_vMJ78xixSR_p-8NpYvoS_O0__8JfWlklvnUUyVo=.6c567162-df54-4a76-85fe-85865bda39fa@github.com>

On Thu, 26 Oct 2023 10:10:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > > > side: given that you are in the neighborhood :) does it make sense to fold the cases for: `ldc2w` and `ldc2` at: `Code::emitop2`?
> 
> This turned out to be a very good suggestion, thanks! While doing it, I realized that we already had a method (`Types::constantType`) to get the `Type` of a constant, so the new method I added to `LoadableConstant` is not really required (and I have now removed it).
> 
> In the end I left the names as they are, beacuse, while confusing, when looking at `emitOp` they kind of make sense - e.g. 1/2 is used to denote the number of operand bytes. So at least it's self-consistent :-)

last version looks good to me, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/16367#issuecomment-1781096417

From mcimadamore at openjdk.org  Thu Oct 26 14:49:44 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Oct 2023 14:49:44 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads [v3]
In-Reply-To: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
Message-ID: <av_NBevMhNIUSu6qXw38GhlTGTi_nJwiR1sHxriHQNU=.e2dc6736-3705-4e1a-a0b6-bbb335131fd7@github.com>

> This PR fixes how javac loads dynamic variable symbols in `Gen` - currently, either a `ldc` or `ldc_w` is emitted. This is problematic, as, depending on the type of the dynamic constant, in some cases `ldc2_w` might be required (e.g. if the type of the constant is either `long` or `double`).
> 
> I've updated the existing compiler condy test to check which `ldc` opcode is emitted for the various constants. I've also verified that the updated test fails w/o the changes in this patch.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16367/files
  - new: https://git.openjdk.org/jdk/pull/16367/files/59c0bfe4..65b85b6a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16367&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16367&range=01-02

  Stats: 14 lines in 1 file changed: 0 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/16367.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16367/head:pull/16367

PR: https://git.openjdk.org/jdk/pull/16367

From mcimadamore at openjdk.org  Thu Oct 26 14:49:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 26 Oct 2023 14:49:46 GMT
Subject: RFR: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads [v2]
In-Reply-To: <WNfAnC98qj2wZZbZAcTWj_6KUyBsJ15xV4Vz2k9jQWs=.e006a938-fa5a-429a-a9f3-4611e7cd98f5@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
 <tcy8P9A51vsKNKkWnYzhT5cy4kap7eZl0y_dPFDuWj4=.84c5823a-4baa-4ccd-9852-9589aca01bcd@github.com>
 <WNfAnC98qj2wZZbZAcTWj_6KUyBsJ15xV4Vz2k9jQWs=.e006a938-fa5a-429a-a9f3-4611e7cd98f5@github.com>
Message-ID: <B0BIs7RdWVIODV-asg0Po5IjQZCNwqESOO0TFcnjBOc=.bbe7a6d8-341a-4644-a300-7f0ae6936618@github.com>

On Thu, 26 Oct 2023 12:29:38 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Looks good to me.
> 
> I wonder if we should also simplify `Items.ImmediateItem.ldc`, since now `Code.emitLdc` handles the long/double on its own?

Good catch - done

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

PR Comment: https://git.openjdk.org/jdk/pull/16367#issuecomment-1781277575

From darcy at openjdk.org  Thu Oct 26 17:36:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 26 Oct 2023 17:36:47 GMT
Subject: RFR: JDK-8306819: Consider disabling the compiler's default active
 annotation processing [v7]
In-Reply-To: <_wWk94od4ReNUx9KM1vOWlWcnw9Q_pO6Wdns-FDleL4=.cf37d33e-32c9-40f5-8f82-5a5443714904@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <nMq4Z3CRz7EPasRmnRcFhnXVLOIkvRjEh0mIj0N5nrs=.87d415f0-c379-49cc-a206-e5c34f8a3052@github.com>
 <Bh2E5JDkTcJhYAFH8lWllkjU9Q3BeKvtyEhf1dVpCU8=.54e720fe-033e-4f02-8c4a-b5a5a223c50c@github.com>
 <7AZJ2h8t-7ZCSTPvPNYpqj_GtG1vjsbVJO5HSpIXwHg=.cb84a0a8-8a13-4987-9bf4-84b12fabb614@github.com>
 <_wWk94od4ReNUx9KM1vOWlWcnw9Q_pO6Wdns-FDleL4=.cf37d33e-32c9-40f5-8f82-5a5443714904@github.com>
Message-ID: <0ivEYgoQy4gJIr7CoDx3QBUHvvZMyWLCDcF1IRkfmAc=.180db207-0f3c-4f1f-98af-d849432092b6@github.com>

On Thu, 26 Oct 2023 03:21:40 GMT, Rob Bygrave <duke at openjdk.org> wrote:

> > there need not be any flag day for changing to JDK 22 specifically since the option to request the old policy is accepted in JDK 21
> 
> Just to say, most of our libs build against **11, 17, 21 and EA/22**. So for this reason our projects we can't trivially make use of `-proc:full` introduced in 21 as that fails the builds using 11 and 17 and instead we needed to introduce build profiles for this.

Noted; thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1781549451

From jjg at openjdk.org  Thu Oct 26 18:48:35 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 26 Oct 2023 18:48:35 GMT
Subject: RFR: 8307168: Inconsistent validation and handling of --system
 flag arguments [v4]
In-Reply-To: <vAUPj-43Mh91uZt4aZUPP6KOpwrxWoY6oFceBQVd16s=.d9e52de9-61b4-4128-9bf2-541ee9bdf84b@github.com>
References: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
 <vAUPj-43Mh91uZt4aZUPP6KOpwrxWoY6oFceBQVd16s=.d9e52de9-61b4-4128-9bf2-541ee9bdf84b@github.com>
Message-ID: <x41pq51aR_iGN-8d9jRa-YFVPTLexJB5TuXBV04qd7s=.d56167cf-1cfc-49f7-8753-0df3bb87b40a@github.com>

On Wed, 25 Oct 2023 06:11:52 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review these changes that fix a bug in `javac`'s validation and handling of `--system` flag arguments.
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update OptionSmokeTest.java

Marked as reviewed by jjg (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16264#pullrequestreview-1700390328

From cstein at openjdk.org  Fri Oct 27 08:40:41 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 27 Oct 2023 08:40:41 GMT
Subject: Integrated: 8307168: Inconsistent validation and handling of --system
 flag arguments
In-Reply-To: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
References: <b5vOHSuBJfseBQputCBst8JS115nycHiw2v7_clRGyY=.67aa342c-1e22-40b3-9553-793b4ce700f0@github.com>
Message-ID: <sGxQWdyBOQd60nQmHPqM5lmHYJE2HSQFN05s9GYv9IU=.4880c4e6-be43-4a58-b78e-f610a1338bb8@github.com>

On Thu, 19 Oct 2023 10:32:16 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review these changes that fix a bug in `javac`'s validation and handling of `--system` flag arguments.

This pull request has now been integrated.

Changeset: 957703b1
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/957703b1f960d739a4a95dd5d8fcb97d41907e5f
Stats:     44 lines in 2 files changed: 35 ins; 0 del; 9 mod

8307168: Inconsistent validation and handling of --system flag arguments

Reviewed-by: jjg

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

PR: https://git.openjdk.org/jdk/pull/16264

From mbaesken at openjdk.org  Fri Oct 27 10:48:38 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 27 Oct 2023 10:48:38 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values and
 max retry attempts
Message-ID: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>

Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.

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

Commit messages:
 - JDK-8318961

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

PR: https://git.openjdk.org/jdk/pull/16397

From cstein at openjdk.org  Fri Oct 27 11:00:40 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 27 Oct 2023 11:00:40 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <Q-_KHeDaVulTBe7ZJj-L_jGoQShRkitQfQqmnK3pWiE=.9660633f-1fd1-4cc3-a893-68715e8d372a@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
 <Q-_KHeDaVulTBe7ZJj-L_jGoQShRkitQfQqmnK3pWiE=.9660633f-1fd1-4cc3-a893-68715e8d372a@github.com>
Message-ID: <vnxcpK0jI8IecSX9IzmtKhwPRa8i9l8lpkXB3YBZRNs=.8a88d2ac-fa40-4e4e-9225-e6786ca7f0c4@github.com>

On Wed, 25 Oct 2023 13:33:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Main method determines the main class now
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 227:
> 
>> 225:         var modulePathModules = modulePathFinder.findAll().stream().map(ModuleReference::descriptor).map(ModuleDescriptor::name).toList();
>> 226:         if (!modulePathModules.isEmpty()) {
>> 227:             var modulePathConfiguration = bootLayer.configuration().resolveAndBind(modulePathFinder, ModuleFinder.of(), Set.copyOf(modulePathModules));
> 
> Some (or all) of the modules on the applications module path may be in the boot layer, I don't think you want to have another instance of these modules in the child layer. So I think check this line, it looks like the first two parameters needs to be swapped so that only modules not found in the boot layer will be resolved.

Will change the line as suggested.

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 228:
> 
>> 226:         if (!modulePathModules.isEmpty()) {
>> 227:             var modulePathConfiguration = bootLayer.configuration().resolveAndBind(modulePathFinder, ModuleFinder.of(), Set.copyOf(modulePathModules));
>> 228:             var modulePathLayer = ModuleLayer.defineModulesWithOneLoader(modulePathConfiguration, List.of(bootLayer), parent).layer();
> 
> Since you don't need the Controller then it may be simpler to use just `bootLayer.defineModulesWithOneLoader(modulePathConfiguration, parent);`

Will change the line as suggested.

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 246:
> 
>> 244:         memoryController.addOpens(module, mainClassNamePackageName, getClass().getModule());
>> 245: 
>> 246:         return memoryLayer.findLoader(applicationModule.name()).loadClass(mainClassName);
> 
> The defining class loader for the main class will be memoryClassLoader, right?

Right. Only the memory class loader has the bytes stored for the main class and other "source-file" classes referenced by the main class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1374406318
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1374405723
PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1374404524

From cstein at openjdk.org  Fri Oct 27 11:04:36 2023
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 27 Oct 2023 11:04:36 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <lt2hx3lOAsl5FkVoaPOoBt2Q0xv4wiAhHtU5e5oLcwk=.ed13369f-2b3f-4d51-b688-1ba2558b114f@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
 <lt2hx3lOAsl5FkVoaPOoBt2Q0xv4wiAhHtU5e5oLcwk=.ed13369f-2b3f-4d51-b688-1ba2558b114f@github.com>
Message-ID: <rEAPUo9x7uP2iRrXRPo3MKDsYeuDlFEKEDPp4sgKB3g=.fe5f6a5e-7870-490a-9f36-59c85a93ef39@github.com>

On Wed, 25 Oct 2023 13:43:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Main method determines the main class now
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 238:
> 
>> 236:         var memoryConfig = parentLayer.configuration().resolveAndBind(memoryFinder, ModuleFinder.of(), Set.of(applicationModule.name()));
>> 237:         var memoryClassLoader = new MemoryClassLoader(inMemoryClasses, parentLoader, applicationModule, descriptor, this::compileJavaFileByName);
>> 238:         var memoryController = ModuleLayer.defineModules(memoryConfig, List.of(parentLayer), __ -> memoryClassLoader);
> 
> It would be helpful if the comment were expanded to explain why memoryClassLoader is needed here. ClassLoaders created by the defineModulesXXX methods are capable to loading modules in memory file systems, the issue is the dynamic compilation (I think).

I'll add a comment explaining that the `MemoryClassLoader` is required here to compile referenced types from their source files on-the-fly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1374409785

From clanger at openjdk.org  Fri Oct 27 11:22:31 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 27 Oct 2023 11:22:31 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values
 and max retry attempts
In-Reply-To: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
Message-ID: <4xXTCk3hr0aMYJhhDqLp6gtuGTLW2kDauzG9mrR1v_A=.791a455f-45a9-4eab-843a-7ce1374d7c88@github.com>

On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.

Looks good to me, these changes seem to have improved nightbuilds at SAP. But somebody from build group should take a look, of course.

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

Marked as reviewed by clanger (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16397#pullrequestreview-1701550622

From mcimadamore at openjdk.org  Fri Oct 27 13:50:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 27 Oct 2023 13:50:42 GMT
Subject: Integrated: 8318837: javac generates wrong ldc instruction for dynamic
 constant loads
In-Reply-To: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
References: <fg-aTDXcvTnxayrumajF_hukryt4tNnsJPlrQNQPrp8=.c7f57771-4b1b-4d2a-9613-0f4665057745@github.com>
Message-ID: <KQKBSfepBxDzPVkUk0HwD2R7Upd-m8gyZRcQZ_cz3N8=.e0cbb769-f474-41e4-a1b4-0d2faa6f83d2@github.com>

On Wed, 25 Oct 2023 17:39:24 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This PR fixes how javac loads dynamic variable symbols in `Gen` - currently, either a `ldc` or `ldc_w` is emitted. This is problematic, as, depending on the type of the dynamic constant, in some cases `ldc2_w` might be required (e.g. if the type of the constant is either `long` or `double`).
> 
> I've updated the existing compiler condy test to check which `ldc` opcode is emitted for the various constants. I've also verified that the updated test fails w/o the changes in this patch.

This pull request has now been integrated.

Changeset: 2915d74a
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2915d74a10c63cdca22d0055ebde67ef316a341b
Stats:     41 lines in 3 files changed: 12 ins; 13 del; 16 mod

8318837: javac generates wrong ldc instruction for dynamic constant loads

Reviewed-by: vromero, jlahoda

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

PR: https://git.openjdk.org/jdk/pull/16367

From acobbs at openjdk.org  Fri Oct 27 14:29:33 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 27 Oct 2023 14:29:33 GMT
Subject: RFR: 8306914: Implementation of JEP Launch Multi-File Source-Code
 Programs [v4]
In-Reply-To: <rEAPUo9x7uP2iRrXRPo3MKDsYeuDlFEKEDPp4sgKB3g=.fe5f6a5e-7870-490a-9f36-59c85a93ef39@github.com>
References: <vqGcXh8Uu5yLOzN3fR628608bY0aZwJhvVCiaLDYuj0=.bbc71686-01d3-4b0a-b6a1-334cd47656ec@github.com>
 <6YBRAUMLKXjqKnphmVLfcLO2R9hpELzPReFgal5kewY=.db9715bc-33da-4669-a5b3-3c18f2defe79@github.com>
 <lt2hx3lOAsl5FkVoaPOoBt2Q0xv4wiAhHtU5e5oLcwk=.ed13369f-2b3f-4d51-b688-1ba2558b114f@github.com>
 <rEAPUo9x7uP2iRrXRPo3MKDsYeuDlFEKEDPp4sgKB3g=.fe5f6a5e-7870-490a-9f36-59c85a93ef39@github.com>
Message-ID: <coxdnsBkac7bXPWBEWQNOvrLG8gb5n8ceQp4KTTA9G4=.0fb543e6-fd12-46f4-8083-eb4f4cea5002@github.com>

On Fri, 27 Oct 2023 11:01:30 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/MemoryContext.java line 238:
>> 
>>> 236:         var memoryConfig = parentLayer.configuration().resolveAndBind(memoryFinder, ModuleFinder.of(), Set.of(applicationModule.name()));
>>> 237:         var memoryClassLoader = new MemoryClassLoader(inMemoryClasses, parentLoader, applicationModule, descriptor, this::compileJavaFileByName);
>>> 238:         var memoryController = ModuleLayer.defineModules(memoryConfig, List.of(parentLayer), __ -> memoryClassLoader);
>> 
>> It would be helpful if the comment were expanded to explain why memoryClassLoader is needed here. ClassLoaders created by the defineModulesXXX methods are capable to loading modules in memory file systems, the issue is the dynamic compilation (I think).
>
> I'll add a comment explaining that the `MemoryClassLoader` is required here to compile referenced types from their source files on-the-fly.

Random comment here, feel free to ignore...

There appear to be two similar implementations of a "Memory" ClassLoader in the JDK... the one under discussion here, and `jdk.jshell.execution.DefaultLoaderDelegate.RemoteClassLoader`. Perhaps someday they could be consolidated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13712#discussion_r1374662423

From erikj at openjdk.org  Fri Oct 27 20:30:31 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 27 Oct 2023 20:30:31 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values
 and max retry attempts
In-Reply-To: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
Message-ID: <cWiJdVPZnHxPXW_9-RJqjqgDLYwMwU7KKNHCK02aQyE=.2d59f646-e47f-413f-9a81-2dfad7e69301@github.com>

On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.

make/langtools/tools/javacserver/client/Client.java line 57:

> 55:     private static final int CONNECTION_TIMEOUT = 4000;
> 56:     private static final int MAX_CONNECT_ATTEMPTS = 10;
> 57:     private static final int WAIT_BETWEEN_CONNECT_ATTEMPTS = 4000;

Not sure increasing the wait time is a good idea. If I'm reading this right, that means 8 seconds between each attempt if they are timing out. Will your problem still be alleviated if we keep the wait time at 2000?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16397#discussion_r1375015595

From cushon at openjdk.org  Fri Oct 27 21:08:42 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 27 Oct 2023 21:08:42 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins across
 compilation boundaries
Message-ID: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>

Hello,

Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).

---

To provide some background context and motivation for the bug fix, consider an example like:


class B {
  @Nullable int f(int x) {
    return x;
  }
}


If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.

If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.

This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.

---

javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.

Some notes on the approach:

* There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.

* For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run the annotation processor on the pre-compiled class. There may be other type annotation tests that could be updated to exercise this change. Overall I think updating the existing extensive test coverage for type annotations avoids duplicating test inputs, and helps ensure both the type annotations for symbols compiled from source and loaded from bytecode match, and that they continue to match when there are changes in the future.

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

Commit messages:
 - 8225377: type annotations are not visible to javac plugins across compilation boundaries

Changes: https://git.openjdk.org/jdk/pull/16407/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8225377
  Stats: 338 lines in 3 files changed: 337 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407

PR: https://git.openjdk.org/jdk/pull/16407

From cushon at openjdk.org  Sat Oct 28 20:39:02 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 28 Oct 2023 20:39:02 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
Message-ID: <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>

> Hello,
> 
> Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> ---
> 
> To provide some background context and motivation for the bug fix, consider an example like:
> 
> 
> class B {
>   @Nullable int f(int x) {
>     return x;
>   }
> }
> 
> 
> If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.
> 
> If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.
> 
> This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.
> 
> ---
> 
> javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.
> 
> Some notes on the approach:
> 
> * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.
> 
> * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Updates
  
  * handle annotating the same type twice (with runtime-visible and
    -invisible annotations)
  * don't throw an assertion on ill-formed type paths
  * null-check ClassSymbol typarams

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16407/files
  - new: https://git.openjdk.org/jdk/pull/16407/files/c25e9b01..82276a77

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=00-01

  Stats: 15 lines in 1 file changed: 12 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/16407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407

PR: https://git.openjdk.org/jdk/pull/16407

From abimpoudis at openjdk.org  Sun Oct 29 08:49:34 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sun, 29 Oct 2023 08:49:34 GMT
Subject: RFR: 8317048: VerifyError with unnamed pattern variable and more
 than one components
In-Reply-To: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>
References: <iMlQZfKQQwFV5Xk4nPcFTEnjeDNnqCzBJrDc7hdfa0U=.22f9b045-d641-4f49-9934-a2d8e47cd24b@github.com>
Message-ID: <-HIn57TaHieqgzBLkKFfnAdhTj2pDw1btFMqPz5HDC4=.8cae7485-f614-42c8-abd8-a894437a7d66@github.com>

On Fri, 29 Sep 2023 10:20:10 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> There were situations when javac optimizes switch structures (by merging the head of cases recursively) when two neighboring cases have a mix of named and unnamed patterns. This resulted translation is like the following:
> 
> From this:
> 
> 
>   static <T1 extends Comparable, T2 extends Comparable> int compareTo(Tuple<R<T1>, R<T2>> o) {
>         return switch (o) {
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R1<T1> _, R2<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> _, R1<T2> _) -> -1;
>             case Tuple<R<T1>, R<T2>>(R2<T1> fst, R2<T2> snd) -> fst.value().compareTo(snd.value());
>         };
>     }
> 
> 
> to code like this from the deeper nested switch (sample taken from `translateTopLevelClass`):
> 
> 
> ...
> case 1:
>    if (!(let snd = (T8317048.R2)selector10$temp; in true)) {
>        index$11 = 2;
>        continue;
>    }
>    yield .value().compareTo(snd.value()); // boom, fst is missing
>    break;
> ...
> 
> 
> The reason is that in the `resolveAccumulator` we peek the first of the two to replace both, in this case the `R2<T1> _`. 
> 
> 
> JCPatternCaseLabel leadingTest = 
>         (JCPatternCaseLabel) accummulator.first().labels.head;
> 
> 
> One way to solve this is to not merge two successive type patterns that have different namings (either both named or both unnamed).

Keep open ?

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

PR Comment: https://git.openjdk.org/jdk/pull/15983#issuecomment-1784037183

From abimpoudis at openjdk.org  Sun Oct 29 18:56:07 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sun, 29 Oct 2023 18:56:07 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v26]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <dFU3FrIW3H4qGmKpwYF_OgvtbHdnbhHoqnLp8iz1ne0=.10c58e38-3437-4f4f-9f7e-767e6f43cd60@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Add tests for new data types in switch statements

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15638/files
  - new: https://git.openjdk.org/jdk/pull/15638/files/fa6256b4..b391a48d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=24-25

  Stats: 74 lines in 1 file changed: 70 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From jlahoda at openjdk.org  Mon Oct 30 09:25:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 30 Oct 2023 09:25:37 GMT
Subject: RFR: 8315532: Compiler Implementation for Unnamed Variables &
 Patterns [v7]
In-Reply-To: <8a80EqSdoXu1bOUwloeZHStv8K0gnCScllreKIa4aYQ=.f4e97671-1d40-4eb8-b4d8-9b0c8d98845e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
 <8a80EqSdoXu1bOUwloeZHStv8K0gnCScllreKIa4aYQ=.f4e97671-1d40-4eb8-b4d8-9b0c8d98845e@github.com>
Message-ID: <13732p4eTxWPfWPYqQfCOQtxr-pIwfK-m_a9vqWrk8g=.4be46ecd-f8f5-4033-8262-234a48b031dd@github.com>

On Wed, 18 Oct 2023 10:29:32 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR finalizes the feature of unnamed variables and patterns.
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove preview lines from a new .out file

Marked as reviewed by jlahoda (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15649#pullrequestreview-1703632660

From mbaesken at openjdk.org  Mon Oct 30 09:29:05 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 09:29:05 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values
 and max retry attempts [v2]
In-Reply-To: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
Message-ID: <q2Xj8iIzclnQV2WnQ99Mn8HgdkjoviEbE44c7HemI40=.8775b9a0-a674-45d7-b316-d25256e4e9c4@github.com>

> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16397/files
  - new: https://git.openjdk.org/jdk/pull/16397/files/314ddfbb..a165403f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16397&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16397&range=00-01

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

PR: https://git.openjdk.org/jdk/pull/16397

From mbaesken at openjdk.org  Mon Oct 30 09:29:06 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 09:29:06 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values
 and max retry attempts
In-Reply-To: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
Message-ID: <4yh3xu72rDdemFBOPLc5ACdDFRYF3b67v7r2GAN2Wu4=.39e2e68e-68b7-40c3-bd37-9c5a59649af1@github.com>

On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.

I adjusted the WAIT_BETWEEN_CONNECT_ATTEMPTS; Let's how this works.

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

PR Comment: https://git.openjdk.org/jdk/pull/16397#issuecomment-1784793547

From abimpoudis at openjdk.org  Mon Oct 30 10:31:46 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 30 Oct 2023 10:31:46 GMT
Subject: Integrated: 8315532: Compiler Implementation for Unnamed Variables &
 Patterns
In-Reply-To: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
References: <hSSGeTgcdECmhhnQVjVHW1kVIDoRLXghBLCX6EJ-VXE=.f100d77a-3e87-442a-b767-6b047785be1e@github.com>
Message-ID: <8_E770JKHeFscUA1hxLwwonER6XtCh4bf2HtLOyF7z4=.38e3250f-e33a-4be0-9a3f-2d6304ccfd67@github.com>

On Sat, 9 Sep 2023 00:02:20 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

> This PR finalizes the feature of unnamed variables and patterns.

This pull request has now been integrated.

Changeset: c9d23c39
Author:    Aggelos Biboudis <abimpoudis at openjdk.org>
Committer: Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c9d23c39405ae3ed90e837753fdaec90c40129b8
Stats:     286 lines in 40 files changed: 133 ins; 89 del; 64 mod

8315532: Compiler Implementation for Unnamed Variables & Patterns
8317221: Implementation for javax.lang.model for Unnamed Variables & Patterns

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Co-authored-by: Gavin Bierman <gbierman at openjdk.org>
Co-authored-by: Brian Goetz <briangoetz at openjdk.org>
Co-authored-by: Joe Darcy <darcy at openjdk.org>
Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: jlahoda, mcimadamore

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

PR: https://git.openjdk.org/jdk/pull/15649

From erikj at openjdk.org  Mon Oct 30 12:53:36 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 30 Oct 2023 12:53:36 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values
 and max retry attempts [v2]
In-Reply-To: <q2Xj8iIzclnQV2WnQ99Mn8HgdkjoviEbE44c7HemI40=.8775b9a0-a674-45d7-b316-d25256e4e9c4@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
 <q2Xj8iIzclnQV2WnQ99Mn8HgdkjoviEbE44c7HemI40=.8775b9a0-a674-45d7-b316-d25256e4e9c4@github.com>
Message-ID: <GDf3ezvv_wcJEEg0C0S87v1GwuE4wQYoD9rjr4AhZJM=.c8a140f6-5510-45dc-9da8-6100c0ec5e6c@github.com>

On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16397#pullrequestreview-1704047915

From mbaesken at openjdk.org  Mon Oct 30 12:59:43 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 12:59:43 GMT
Subject: RFR: JDK-8318961: increase javacserver connection timeout values
 and max retry attempts [v2]
In-Reply-To: <q2Xj8iIzclnQV2WnQ99Mn8HgdkjoviEbE44c7HemI40=.8775b9a0-a674-45d7-b316-d25256e4e9c4@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
 <q2Xj8iIzclnQV2WnQ99Mn8HgdkjoviEbE44c7HemI40=.8775b9a0-a674-45d7-b316-d25256e4e9c4@github.com>
Message-ID: <EIIPQPEqvUktAU2Oy-MVmE2xTSn5FRcYPH5j8Iw4L_Y=.fdc0af5c-8a0a-475b-8582-4c9a6830b68a@github.com>

On Mon, 30 Oct 2023 09:29:05 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust WAIT_BETWEEN_CONNECT_ATTEMPTS

Hi Christoph and Erik, thanks for the reviews !

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

PR Comment: https://git.openjdk.org/jdk/pull/16397#issuecomment-1785134884

From mbaesken at openjdk.org  Mon Oct 30 12:59:43 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 30 Oct 2023 12:59:43 GMT
Subject: Integrated: JDK-8318961: increase javacserver connection timeout
 values and max retry attempts
In-Reply-To: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
References: <JmnSZDcledAGNId4tbcG1T2LSNsFzas5HRVccdLizpo=.7ce16c69-696c-4f0a-afa0-40d290748025@github.com>
Message-ID: <8W9He6c83m-i9NKfP3YwYaZOQUmNsMupvHyphYsS_NY=.f40034df-dd3e-42fa-802b-e9ac4456f7f8@github.com>

On Fri, 27 Oct 2023 10:43:58 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Increase javacserver connection timeout values and max retry attempts for better make stability on some slower machines.

This pull request has now been integrated.

Changeset: b9983c72
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9983c72295a31e5f5079bc96c892177fbea3a6e
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8318961: increase javacserver connection timeout values and max retry attempts

Reviewed-by: clanger, erikj

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

PR: https://git.openjdk.org/jdk/pull/16397

From vromero at openjdk.org  Mon Oct 30 18:42:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Oct 2023 18:42:35 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
Message-ID: <P0P6vx5Mh7Fj2R1Yf_qVu4Wr_JileSWGiHHXAsp3-2M=.60da1b72-6ec9-4b90-9cf9-dbf05b9be95b@github.com>

On Sat, 28 Oct 2023 20:39:02 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hello,
>> 
>> Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).
>> 
>> ---
>> 
>> To provide some background context and motivation for the bug fix, consider an example like:
>> 
>> 
>> class B {
>>   @Nullable int f(int x) {
>>     return x;
>>   }
>> }
>> 
>> 
>> If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.
>> 
>> If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.
>> 
>> This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.
>> 
>> ---
>> 
>> javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.
>> 
>> Some notes on the approach:
>> 
>> * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.
>> 
>> * For initial test coverage, I have enabled test covera...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates
>   
>   * handle annotating the same type twice (with runtime-visible and
>     -invisible annotations)
>   * don't throw an assertion on ill-formed type paths
>   * null-check ClassSymbol typarams

the code in TypeAnnotationMapper looks good to me, actually simpler than expected. I just wonder if it should be placed inside of ClassReader, if you want to keep it separated please consider not exposing its API as static methods.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2264:

> 2262:                 List<Attribute.TypeCompound> newList = deproxyTypeCompoundList(proxies);
> 2263:                 sym.setTypeAttributes(newList.prependList(sym.getRawTypeAttributes()));
> 2264:                 TypeAnnotationMapper.addTypeAnnotationsToSymbol(sym, newList);

I wonder if the new TypeAnnotationsMapper should actually live inside of ClassReader

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

PR Review: https://git.openjdk.org/jdk/pull/16407#pullrequestreview-1704837433
PR Review Comment: https://git.openjdk.org/jdk/pull/16407#discussion_r1376657664

From cushon at openjdk.org  Mon Oct 30 20:57:51 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 30 Oct 2023 20:57:51 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v3]
In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
Message-ID: <bQ5aTB7ys-i5Yt3YFciYJWgg8-H76mgWp_EuHLuXsIk=.4f1f5bbb-58ba-405d-a857-77d8b18f1f79@github.com>

> Hello,
> 
> Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> ---
> 
> To provide some background context and motivation for the bug fix, consider an example like:
> 
> 
> class B {
>   @Nullable int f(int x) {
>     return x;
>   }
> }
> 
> 
> If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.
> 
> If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.
> 
> This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.
> 
> ---
> 
> javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.
> 
> Some notes on the approach:
> 
> * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.
> 
> * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Inline TypeAnnotationsMapper into ClassReader

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16407/files
  - new: https://git.openjdk.org/jdk/pull/16407/files/82276a77..52c01409

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=01-02

  Stats: 638 lines in 2 files changed: 291 ins; 346 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407

PR: https://git.openjdk.org/jdk/pull/16407

From cushon at openjdk.org  Mon Oct 30 20:57:55 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 30 Oct 2023 20:57:55 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
Message-ID: <VnrxgdnWSA9WUneKsXtKlnJ5eA-rp-IK_lQTG6pvaLI=.cc54b613-359d-4c48-ac26-af0f5c75eb9b@github.com>

On Sat, 28 Oct 2023 20:39:02 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hello,
>> 
>> Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).
>> 
>> ---
>> 
>> To provide some background context and motivation for the bug fix, consider an example like:
>> 
>> 
>> class B {
>>   @Nullable int f(int x) {
>>     return x;
>>   }
>> }
>> 
>> 
>> If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.
>> 
>> If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.
>> 
>> This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.
>> 
>> ---
>> 
>> javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.
>> 
>> Some notes on the approach:
>> 
>> * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.
>> 
>> * For initial test coverage, I have enabled test covera...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates
>   
>   * handle annotating the same type twice (with runtime-visible and
>     -invisible annotations)
>   * don't throw an assertion on ill-formed type paths
>   * null-check ClassSymbol typarams

Thanks for the review!

> I just wonder if it should be placed inside of ClassReader, if you want to keep it separated please consider not exposing its API as static methods.

Moving it into ClassReader is fine with me. I initially thought it might end up requiring more logic than it did. I left it in a separate class because it's still a medium amount of logic and is fairly self-contained, but if you're preference is to move it into ClassReader I'm happy to proceed with that.

Just for my understanding, if it was a separate class would the preferred style be to register it in `Context` and have `ClassReader` create an instance of it?

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

PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1786024913

From cushon at openjdk.org  Mon Oct 30 20:57:58 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 30 Oct 2023 20:57:58 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <P0P6vx5Mh7Fj2R1Yf_qVu4Wr_JileSWGiHHXAsp3-2M=.60da1b72-6ec9-4b90-9cf9-dbf05b9be95b@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
 <P0P6vx5Mh7Fj2R1Yf_qVu4Wr_JileSWGiHHXAsp3-2M=.60da1b72-6ec9-4b90-9cf9-dbf05b9be95b@github.com>
Message-ID: <MzFUg4k8SwKdeerjSqY1FojYPPrbgpwDBprwIoHwCfw=.33cda169-d870-4baf-8c7a-e27348b0d635@github.com>

On Mon, 30 Oct 2023 18:36:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updates
>>   
>>   * handle annotating the same type twice (with runtime-visible and
>>     -invisible annotations)
>>   * don't throw an assertion on ill-formed type paths
>>   * null-check ClassSymbol typarams
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 2264:
> 
>> 2262:                 List<Attribute.TypeCompound> newList = deproxyTypeCompoundList(proxies);
>> 2263:                 sym.setTypeAttributes(newList.prependList(sym.getRawTypeAttributes()));
>> 2264:                 TypeAnnotationMapper.addTypeAnnotationsToSymbol(sym, newList);
> 
> I wonder if the new TypeAnnotationsMapper should actually live inside of ClassReader

I have tentatively gone ahead and moved it into ClassReader

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16407#discussion_r1376790553

From cushon at openjdk.org  Mon Oct 30 21:16:43 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 30 Oct 2023 21:16:43 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v4]
In-Reply-To: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
Message-ID: <dol_tOFq7vKXzOOf0hB708xZF3nd-qYATVfvUCJcP0k=.bc3a7894-850f-48b5-a7dc-672233e4fb36@github.com>

> Hello,
> 
> Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).
> 
> ---
> 
> To provide some background context and motivation for the bug fix, consider an example like:
> 
> 
> class B {
>   @Nullable int f(int x) {
>     return x;
>   }
> }
> 
> 
> If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.
> 
> If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.
> 
> This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.
> 
> ---
> 
> javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.
> 
> Some notes on the approach:
> 
> * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.
> 
> * For initial test coverage, I have enabled test coverage for annotation processing of type annotations to also run t...

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Formatting

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16407/files
  - new: https://git.openjdk.org/jdk/pull/16407/files/52c01409..14b6bbd9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=16407&range=02-03

  Stats: 27 lines in 1 file changed: 10 ins; 1 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16407.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16407/head:pull/16407

PR: https://git.openjdk.org/jdk/pull/16407

From vromero at openjdk.org  Mon Oct 30 21:48:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Oct 2023 21:48:31 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <VnrxgdnWSA9WUneKsXtKlnJ5eA-rp-IK_lQTG6pvaLI=.cc54b613-359d-4c48-ac26-af0f5c75eb9b@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
 <VnrxgdnWSA9WUneKsXtKlnJ5eA-rp-IK_lQTG6pvaLI=.cc54b613-359d-4c48-ac26-af0f5c75eb9b@github.com>
Message-ID: <zMsjteDUrLPXsb0uRYv3Zq-qbKPOt97K7nwfkDQLMSc=.b2b47d2e-8e11-431b-8bd3-8c65c052ec74@github.com>

On Mon, 30 Oct 2023 20:55:04 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> Thanks for the review!
> 
> > I just wonder if it should be placed inside of ClassReader, if you want to keep it separated please consider not exposing its API as static methods.
> 
> Moving it into ClassReader is fine with me. I initially thought it might end up requiring more logic than it did. I left it in a separate class because it's still a medium amount of logic and is fairly self-contained, but if you're preference is to move it into ClassReader I'm happy to proceed with that.
> 
> Just for my understanding, if it was a separate class would the preferred style be to register it in `Context` and have `ClassReader` create an instance of it?

if it was a separate instance I would prefer ClassReader to create an instance of it even it it is not registered in Context, but registering it in Context would be the "standard" approach I think

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

PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1786097433

From abimpoudis at openjdk.org  Mon Oct 30 22:27:18 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Mon, 30 Oct 2023 22:27:18 GMT
Subject: RFR: 8303374: Compiler Implementation for Primitive types in
 patterns, instanceof, and switch (Preview) [v27]
In-Reply-To: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
Message-ID: <4L-TUvaw9p-MEi5GpE8XI1XhCOcIVdtPGn5kLdnUU3U=.d635720d-68a6-4848-8aa6-61ac42fbc6e3@github.com>

> This is the proposed patch for Primitive types in patterns, instanceof, and switch (Preview).
> 
> Draft spec here: https://cr.openjdk.org/~abimpoudis/instanceof/jep443-20231010/specs/instanceof-jls.html

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into primitive-patterns
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java
 - Add tests for new data types in switch statements
 - Fix Bootstrap initialization error by using `explicitCastArguments` for integral tests
 - Fix SwitchBootstraps for pattern matching over longs
 - Merge branch 'master' into primitive-patterns
 - Improve javadoc of ExactConversionsSupport
   
   Co-authored-by: Raffaello Giulietti <raffaello.giulietti at oracle.com>
 - Adjust javadoc on ExactConversionsSupport
 - Merge branch 'master' into primitive-patterns
 - Address review
   
   - Add comments
   - Rename exactness methods
   - Use convenience methods from TypeTag for checkUnconditionallyExactPrimitives in Types
   - Port isStrictSubRangeOf to Wrapper and use it for unconditionalExactnessCheck in SwitchBootstraps
 - Fix duplicate method name and add a new test in PrimitivePatternsSwitchErrors
 - ... and 23 more: https://git.openjdk.org/jdk/compare/1ca2cfaf...b437373b

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

Changes: https://git.openjdk.org/jdk/pull/15638/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15638&range=26
  Stats: 3055 lines in 40 files changed: 2799 ins; 111 del; 145 mod
  Patch: https://git.openjdk.org/jdk/pull/15638.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15638/head:pull/15638

PR: https://git.openjdk.org/jdk/pull/15638

From cushon at openjdk.org  Mon Oct 30 23:18:35 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 30 Oct 2023 23:18:35 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <zMsjteDUrLPXsb0uRYv3Zq-qbKPOt97K7nwfkDQLMSc=.b2b47d2e-8e11-431b-8bd3-8c65c052ec74@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
 <VnrxgdnWSA9WUneKsXtKlnJ5eA-rp-IK_lQTG6pvaLI=.cc54b613-359d-4c48-ac26-af0f5c75eb9b@github.com>
 <zMsjteDUrLPXsb0uRYv3Zq-qbKPOt97K7nwfkDQLMSc=.b2b47d2e-8e11-431b-8bd3-8c65c052ec74@github.com>
Message-ID: <HOtiItzrN_eGGv-qIxymJNx16p1VgkZtMS4Pj-Ed-p0=.0546feeb-30f0-4337-bcdb-d7d1bd570284@github.com>

On Mon, 30 Oct 2023 21:45:42 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> if it was a separate instance I would prefer ClassReader to create an instance of it even it it is not registered in Context, but registering it in Context would be the "standard" approach I think

Sounds good, thanks. I'm happy to implement whichever of these options you prefer. Do you prefer having the logic in ClassReader, or a separate class that ClassReader creates an instance of?

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

PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1786191021

From vromero at openjdk.org  Mon Oct 30 23:49:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Oct 2023 23:49:32 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v4]
In-Reply-To: <dol_tOFq7vKXzOOf0hB708xZF3nd-qYATVfvUCJcP0k=.bc3a7894-850f-48b5-a7dc-672233e4fb36@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <dol_tOFq7vKXzOOf0hB708xZF3nd-qYATVfvUCJcP0k=.bc3a7894-850f-48b5-a7dc-672233e4fb36@github.com>
Message-ID: <QBs3SfCg1RhSVfoMUvRwTnJLY4ilbPdt9LxTtgkqG6o=.d69807a0-156c-4bec-b62a-de16c44821ef@github.com>

On Mon, 30 Oct 2023 21:16:43 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Hello,
>> 
>> Please consider this fix for [JDK-8225377: type annotations are not visible to javac plugins across compilation boundaries](https://bugs.openjdk.org/browse/JDK-8225377).
>> 
>> ---
>> 
>> To provide some background context and motivation for the bug fix, consider an example like:
>> 
>> 
>> class B {
>>   @Nullable int f(int x) {
>>     return x;
>>   }
>> }
>> 
>> 
>> If `@Nullable` is a `@Target(METHOD)` annotation, an annotation processor can retrieve the annotation by from the  `ExecutableElement` for `f` by calling `getAnnotationMirrors()`. This is true regardless of whether `B` is being compiled from source in the current compilation, or loaded from a class file.
>> 
>> If `@Nullable` is a `@Target(TYPE_USE)` annotation, an annotation processor should be able to retrieve the annotation by locating the `ExecutableElement` for `f`, and calling `getReturnType().getAnnotationMirrors()`. This works today if `B` is compiled from source, but (due to [JDK-8225377](https://bugs.openjdk.org/browse/JDK-8225377)) not if `B` is loaded from a class file.
>> 
>> This is a hurdle to migrating from existing declaration annotations to `@Target(TYPE_USE)` annotations for use-cases like `@Nullable`. For example: a dependency injection framework might use an annotation processor to generate code, and that code would want to know if a formal parameter type accepted `null` values, or if a method returned `null` values. That works today with declaration annotation definitions of `@Nullable`, and this fix will allow it work with `TYPE_USE` definitions of `@Nullable` in the future.
>> 
>> ---
>> 
>> javac already reads type annotation information from `Runtime{Visible,Invisible}TypeAnnotations` attributes in class files, and `ClassReader` registers a completer that calls `Symbol#setTypeAttributes` to add the type annotations to the symbol's metadata. This change adds logic to associate those annotations with the corresponding type contained in the symbol.
>> 
>> Some notes on the approach:
>> 
>> * There are some similarities between the logic being added and existing logic in `TypeAnnotations`, but `TypeAnnotations` operates on the AST, and is solving different problems. In the AST annotations are already adjacent to the type they are annotating, and in bytecode they have been separated out and the implementation has to interpret the annotation target and type path information to match the annotations back up with their types.
>> 
>> * For initial test coverage, I have enabled test covera...
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Formatting

looks good to me

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16407#pullrequestreview-1705236953

From vromero at openjdk.org  Mon Oct 30 23:49:33 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 30 Oct 2023 23:49:33 GMT
Subject: RFR: 8225377: type annotations are not visible to javac plugins
 across compilation boundaries [v2]
In-Reply-To: <HOtiItzrN_eGGv-qIxymJNx16p1VgkZtMS4Pj-Ed-p0=.0546feeb-30f0-4337-bcdb-d7d1bd570284@github.com>
References: <9oHc5aBG4b54FTum6j2V8hgTymM0hVFO8gdu9TO-QsU=.e5f5296b-2fae-45e8-a6bd-4001924b8b5a@github.com>
 <v48AwvuoqQvnKHrkJ1pmrcLqRuRGr0Lh5fAtl1N_I1Y=.3303f93c-4fed-4460-9361-898c6277ca0d@github.com>
 <VnrxgdnWSA9WUneKsXtKlnJ5eA-rp-IK_lQTG6pvaLI=.cc54b613-359d-4c48-ac26-af0f5c75eb9b@github.com>
 <zMsjteDUrLPXsb0uRYv3Zq-qbKPOt97K7nwfkDQLMSc=.b2b47d2e-8e11-431b-8bd3-8c65c052ec74@github.com>
 <HOtiItzrN_eGGv-qIxymJNx16p1VgkZtMS4Pj-Ed-p0=.0546feeb-30f0-4337-bcdb-d7d1bd570284@github.com>
Message-ID: <wNj6sJoOckusd97kXykN8ka-dtOYNzgLjylToOg8lUk=.f0517bc3-c772-4669-aba8-e324c1fe7716@github.com>

On Mon, 30 Oct 2023 23:15:37 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> > if it was a separate instance I would prefer ClassReader to create an instance of it even it it is not registered in Context, but registering it in Context would be the "standard" approach I think
> 
> Sounds good, thanks. I'm happy to implement whichever of these options you prefer. Do you prefer having the logic in ClassReader, or a separate class that ClassReader creates an instance of?

I'm OK with the last version, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/16407#issuecomment-1786216684

From maurizio.cimadamore at oracle.com  Tue Oct 31 14:14:18 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 31 Oct 2023 14:14:18 +0000
Subject: JMH and JDK 22
Message-ID: <986933cd-c9a0-4003-857f-bb2aadbacd84@oracle.com>

Hi,
earlier today I ran into an issue when trying to run a JMH benchmark on 
a 3rd party maven project.

It seems like the issue is caused by the change in javac?s default 
annotation processing policy [1].

Here are the steps to reproduce the issue:

  * set JAVA_HOME to point to a recent JDK 22 build
  * generate a JMH sample pom file using the following command (this is
    what is advertised in the JMH github page [2]):

|$ mvn archetype:generate \ -DinteractiveMode=false \ 
-DarchetypeGroupId=org.openjdk.jmh \ 
-DarchetypeArtifactId=jmh-java-benchmark-archetype \ 
-DgroupId=org.sample \ -DartifactId=test \ -Dversion=1.0 |

  * build the project using |mvn clean package|
  * run the benchmark as follows:

|$ $JAVA_HOME/bin/java -jar target/benchmarks.jar MyBenchmark Exception 
in thread "main" java.lang.RuntimeException: ERROR: Unable to find the 
resource: /META-INF/BenchmarkList at 
org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98) 
at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124) at 
org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252) at 
org.openjdk.jmh.runner.Runner.run(Runner.java:208) at 
org.openjdk.jmh.Main.main(Main.java:71) |

As you can see, there is a problem here, as the META-INF folder does not 
contain the list of benchmarks. This is due to the fact that annotations 
are no longer processed using processors available in the classpath. 
Using JDK 21 to build and run the same pom file works fine.

Adding the following lines to the compiler plugin configuration 
addresses the issue in JDK 22:

|<compilerArgs> <arg>-proc:full</arg> </compilerArgs> |

While this is understandable, I?m afraid that not many users will have 
gotten the memo - I don?t seem to get any notes when building this 
project using JDK 21 (probably the notes are swallowed by maven?). And, 
sadly, the lack of a proper JMH plugin means that all the JMH poms out 
there will need some manual tweaking to keep working in 22.

At the very least, I think that JMH?s maven archetype should be updated 
to include the lines above?

Cheers
Maurizio

[1] - https://github.com/openjdk/jdk/pull/14432
[2] - https://github.com/openjdk/jmh

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231031/5e4173a1/attachment-0001.htm>

From jai.forums2013 at gmail.com  Tue Oct 31 15:16:05 2023
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 31 Oct 2023 20:46:05 +0530
Subject: JMH and JDK 22
In-Reply-To: <986933cd-c9a0-4003-857f-bb2aadbacd84@oracle.com>
References: <986933cd-c9a0-4003-857f-bb2aadbacd84@oracle.com>
Message-ID: <1dcabbb5-a83c-4c8a-99e5-85c4d99b9d9b@gmail.com>

Hello Maurizio,

We had this issue in our JDK repo which has micro benchmarks. Running 
those micro benchmarks had run into this issue. We decided to use the 
"-processor org.openjdk.jmh.generators.BenchmarkProcessor" instead of 
-proc:full to get this to work. More details are available here 
https://github.com/openjdk/jdk/pull/16122

-Jaikiran

On 31/10/23 7:44 pm, Maurizio Cimadamore wrote:
>
> Hi,
> earlier today I ran into an issue when trying to run a JMH benchmark 
> on a 3rd party maven project.
>
> It seems like the issue is caused by the change in javac?s default 
> annotation processing policy [1].
>
> Here are the steps to reproduce the issue:
>
>   * set JAVA_HOME to point to a recent JDK 22 build
>   * generate a JMH sample pom file using the following command (this
>     is what is advertised in the JMH github page [2]):
>
> |$ mvn archetype:generate \ -DinteractiveMode=false \ 
> -DarchetypeGroupId=org.openjdk.jmh \ 
> -DarchetypeArtifactId=jmh-java-benchmark-archetype \ 
> -DgroupId=org.sample \ -DartifactId=test \ -Dversion=1.0 |
>
>   * build the project using |mvn clean package|
>   * run the benchmark as follows:
>
> |$ $JAVA_HOME/bin/java -jar target/benchmarks.jar MyBenchmark 
> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable 
> to find the resource: /META-INF/BenchmarkList at 
> org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98) 
> at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124) 
> at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252) at 
> org.openjdk.jmh.runner.Runner.run(Runner.java:208) at 
> org.openjdk.jmh.Main.main(Main.java:71) |
>
> As you can see, there is a problem here, as the META-INF folder does 
> not contain the list of benchmarks. This is due to the fact that 
> annotations are no longer processed using processors available in the 
> classpath. Using JDK 21 to build and run the same pom file works fine.
>
> Adding the following lines to the compiler plugin configuration 
> addresses the issue in JDK 22:
>
> |<compilerArgs> <arg>-proc:full</arg> </compilerArgs> |
>
> While this is understandable, I?m afraid that not many users will have 
> gotten the memo - I don?t seem to get any notes when building this 
> project using JDK 21 (probably the notes are swallowed by maven?). 
> And, sadly, the lack of a proper JMH plugin means that all the JMH 
> poms out there will need some manual tweaking to keep working in 22.
>
> At the very least, I think that JMH?s maven archetype should be 
> updated to include the lines above?
>
> Cheers
> Maurizio
>
> [1] - https://github.com/openjdk/jdk/pull/14432
> [2] - https://github.com/openjdk/jmh
>
> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231031/1fbc2bae/attachment.htm>

From maurizio.cimadamore at oracle.com  Tue Oct 31 15:18:32 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 31 Oct 2023 15:18:32 +0000
Subject: JMH and JDK 22
In-Reply-To: <1dcabbb5-a83c-4c8a-99e5-85c4d99b9d9b@gmail.com>
References: <986933cd-c9a0-4003-857f-bb2aadbacd84@oracle.com>
 <1dcabbb5-a83c-4c8a-99e5-85c4d99b9d9b@gmail.com>
Message-ID: <8feebd08-3617-4ed0-acac-6236289390da@oracle.com>

Hi Jaikiran,
I'm aware of the issue you mention. To clarify, here I'm talking about 
benchmarks that live _outside_ the JDK (which is arguably a common case).

What my pom file changes do is morally equivalent to the JDK build 
changes linked in your JBS issue.

Maurizio

On 31/10/2023 15:16, Jaikiran Pai wrote:
>
> Hello Maurizio,
>
> We had this issue in our JDK repo which has micro benchmarks. Running 
> those micro benchmarks had run into this issue. We decided to use the 
> "-processor org.openjdk.jmh.generators.BenchmarkProcessor" instead of 
> -proc:full to get this to work. More details are available here 
> https://github.com/openjdk/jdk/pull/16122
>
> -Jaikiran
>
> On 31/10/23 7:44 pm, Maurizio Cimadamore wrote:
>>
>> Hi,
>> earlier today I ran into an issue when trying to run a JMH benchmark 
>> on a 3rd party maven project.
>>
>> It seems like the issue is caused by the change in javac?s default 
>> annotation processing policy [1].
>>
>> Here are the steps to reproduce the issue:
>>
>>   * set JAVA_HOME to point to a recent JDK 22 build
>>   * generate a JMH sample pom file using the following command (this
>>     is what is advertised in the JMH github page [2]):
>>
>> |$ mvn archetype:generate \ -DinteractiveMode=false \ 
>> -DarchetypeGroupId=org.openjdk.jmh \ 
>> -DarchetypeArtifactId=jmh-java-benchmark-archetype \ 
>> -DgroupId=org.sample \ -DartifactId=test \ -Dversion=1.0 |
>>
>>   * build the project using |mvn clean package|
>>   * run the benchmark as follows:
>>
>> |$ $JAVA_HOME/bin/java -jar target/benchmarks.jar MyBenchmark 
>> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable 
>> to find the resource: /META-INF/BenchmarkList at 
>> org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98) 
>> at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124) 
>> at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252) at 
>> org.openjdk.jmh.runner.Runner.run(Runner.java:208) at 
>> org.openjdk.jmh.Main.main(Main.java:71) |
>>
>> As you can see, there is a problem here, as the META-INF folder does 
>> not contain the list of benchmarks. This is due to the fact that 
>> annotations are no longer processed using processors available in the 
>> classpath. Using JDK 21 to build and run the same pom file works fine.
>>
>> Adding the following lines to the compiler plugin configuration 
>> addresses the issue in JDK 22:
>>
>> |<compilerArgs> <arg>-proc:full</arg> </compilerArgs> |
>>
>> While this is understandable, I?m afraid that not many users will 
>> have gotten the memo - I don?t seem to get any notes when building 
>> this project using JDK 21 (probably the notes are swallowed by 
>> maven?). And, sadly, the lack of a proper JMH plugin means that all 
>> the JMH poms out there will need some manual tweaking to keep working 
>> in 22.
>>
>> At the very least, I think that JMH?s maven archetype should be 
>> updated to include the lines above?
>>
>> Cheers
>> Maurizio
>>
>> [1] - https://github.com/openjdk/jdk/pull/14432
>> [2] - https://github.com/openjdk/jmh
>>
>> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231031/1ba77e90/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Tue Oct 31 15:28:04 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 31 Oct 2023 15:28:04 +0000
Subject: JMH and JDK 22
In-Reply-To: <0660b0a9-d2b7-474a-bc81-1fc33a892fef@gmail.com>
References: <986933cd-c9a0-4003-857f-bb2aadbacd84@oracle.com>
 <1dcabbb5-a83c-4c8a-99e5-85c4d99b9d9b@gmail.com>
 <8feebd08-3617-4ed0-acac-6236289390da@oracle.com>
 <0660b0a9-d2b7-474a-bc81-1fc33a892fef@gmail.com>
Message-ID: <baa07f2a-c584-4b6c-afbd-a12c9bb43533@oracle.com>


On 31/10/2023 15:27, Jaikiran Pai wrote:
> I didn't word my previous reply clearly. What I meant to say was, if 
> the jmh archetype generator gets updated to by default add the option, 
> then I think it would be better to only enable the specific annotation 
> processor using the -processor option instead of -proc:full. That way 
> it won't end up enabling all other annotation processors that might be 
> on the classpath (which is what I believe was the motivation behind 
> not enabling the annotation processors by default).

Sure - that's a better way to do it for sure

Maurizio


From ethan at mccue.dev  Tue Oct 31 15:30:01 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Tue, 31 Oct 2023 11:30:01 -0400
Subject: RFR: JDK-8306819: Consider disabling the compiler's default
 active annotation processing
In-Reply-To: <n8w-GhXtubyEQTs58LG2v5mQ_w8ZxrCeFg-ywgA8ueE=.4acd4926-9784-49c5-a92e-56a801879676@github.com>
References: <2iXdVG-MCaakXx5C5y01mcOFxJNEhoG4o2Fi_KlK8Co=.b500ce4e-7c4b-4d30-b489-f338f86f8af8@github.com>
 <ctyp7mU8n-kwOhn4FosdIiu1yPPPDyOFcghxoqRt2Fo=.3cbdddea-f8b0-40a8-a3f0-b797121c6996@github.com>
 <L9f6RG36zl89Hagzn-Nba6sdIOh168DW3IehpbpUBy0=.3e73cb95-ebc1-48cb-993b-f230cf6b9dfa@github.com>
 <J5FV_g0pT-VKq8I5-9Jg0Q1G5u5LHTtmA9zX-HUN64o=.55324e37-9f2a-4e49-8e5b-7e150cae1510@github.com>
 <n8w-GhXtubyEQTs58LG2v5mQ_w8ZxrCeFg-ywgA8ueE=.4acd4926-9784-49c5-a92e-56a801879676@github.com>
Message-ID: <CA+NR86gtzehoACWw6wvCUp6jKHTzEWhpof4smXy2g=jeO+_62w@mail.gmail.com>

I'm still unclear why this change is not going through the same general
process as JEP 451.



On Fri, Oct 20, 2023 at 9:45?PM Joe Darcy <darcy at openjdk.org> wrote:

> On Sun, 10 Sep 2023 22:57:30 GMT, Rob Bygrave <duke at openjdk.org> wrote:
>
> > > This patch isn't aimed to remove AP. This aims to avoid unintentional
> AP pollutions in classpath
> >
> > Yes, I understand that.
> >
> > > Such classpath separation have already been promoted by build tools
> like Gradle.
> >
> > **_BUT_** it has **_NOT_** been promoted by **_Maven_**. In the bug
> report and in this PR I do not see any explicit recognition of how this
> change will impact the community that is using Maven and I am suggesting
> that this is a significant proportion of the community.
> >
> > For example, all the libraries that use annotation processing that
> document maven use could be impacted along the lines that their
> documentation will now be at least misleading (and sometimes incorrect).
> >
> > This change might indeed be a good long term change but it seems to be
> being made without any recognition or understanding of how impactful it
> will be.
>
> Maven is listed as a participant in the OpenJDK Quality Outreach effort (
> https://wiki.openjdk.org/display/quality/Quality+Outreach).
>
> The prior change of the javac emitting the note was explicitly raised on
> the quality discuss alias in July 2023 (
> https://mail.openjdk.org/pipermail/quality-discuss/2023-July/thread.html),
> ahead of the GA of JDK 21 in September.
>
> The change in this PR is likewise publicized this the October 2023 quality
> discuss message (
> https://mail.openjdk.org/pipermail/quality-discuss/2023-October/001129.html),
> months ahead of the expected GA of JDK 23 in March 2024.
>
> -------------
>
> PR Comment: https://git.openjdk.org/jdk/pull/14432#issuecomment-1773592750
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231031/7714b571/attachment.htm>

From jai.forums2013 at gmail.com  Tue Oct 31 15:27:11 2023
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Tue, 31 Oct 2023 20:57:11 +0530
Subject: JMH and JDK 22
In-Reply-To: <8feebd08-3617-4ed0-acac-6236289390da@oracle.com>
References: <986933cd-c9a0-4003-857f-bb2aadbacd84@oracle.com>
 <1dcabbb5-a83c-4c8a-99e5-85c4d99b9d9b@gmail.com>
 <8feebd08-3617-4ed0-acac-6236289390da@oracle.com>
Message-ID: <0660b0a9-d2b7-474a-bc81-1fc33a892fef@gmail.com>


On 31/10/23 8:48 pm, Maurizio Cimadamore wrote:
>
> Hi Jaikiran,
> I'm aware of the issue you mention. To clarify, here I'm talking about 
> benchmarks that live _outside_ the JDK (which is arguably a common case).
>
Noted.
>
> What my pom file changes do is morally equivalent to the JDK build 
> changes linked in your JBS issue.
>
I didn't word my previous reply clearly. What I meant to say was, if the 
jmh archetype generator gets updated to by default add the option, then 
I think it would be better to only enable the specific annotation 
processor using the -processor option instead of -proc:full. That way it 
won't end up enabling all other annotation processors that might be on 
the classpath (which is what I believe was the motivation behind not 
enabling the annotation processors by default).

-Jaikiran


> Maurizio
>
> On 31/10/2023 15:16, Jaikiran Pai wrote:
>>
>> Hello Maurizio,
>>
>> We had this issue in our JDK repo which has micro benchmarks. Running 
>> those micro benchmarks had run into this issue. We decided to use the 
>> "-processor org.openjdk.jmh.generators.BenchmarkProcessor" instead of 
>> -proc:full to get this to work. More details are available here 
>> https://github.com/openjdk/jdk/pull/16122
>>
>> -Jaikiran
>>
>> On 31/10/23 7:44 pm, Maurizio Cimadamore wrote:
>>>
>>> Hi,
>>> earlier today I ran into an issue when trying to run a JMH benchmark 
>>> on a 3rd party maven project.
>>>
>>> It seems like the issue is caused by the change in javac?s default 
>>> annotation processing policy [1].
>>>
>>> Here are the steps to reproduce the issue:
>>>
>>>   * set JAVA_HOME to point to a recent JDK 22 build
>>>   * generate a JMH sample pom file using the following command (this
>>>     is what is advertised in the JMH github page [2]):
>>>
>>> |$ mvn archetype:generate \ -DinteractiveMode=false \ 
>>> -DarchetypeGroupId=org.openjdk.jmh \ 
>>> -DarchetypeArtifactId=jmh-java-benchmark-archetype \ 
>>> -DgroupId=org.sample \ -DartifactId=test \ -Dversion=1.0 |
>>>
>>>   * build the project using |mvn clean package|
>>>   * run the benchmark as follows:
>>>
>>> |$ $JAVA_HOME/bin/java -jar target/benchmarks.jar MyBenchmark 
>>> Exception in thread "main" java.lang.RuntimeException: ERROR: Unable 
>>> to find the resource: /META-INF/BenchmarkList at 
>>> org.openjdk.jmh.runner.AbstractResourceReader.getReaders(AbstractResourceReader.java:98) 
>>> at org.openjdk.jmh.runner.BenchmarkList.find(BenchmarkList.java:124) 
>>> at org.openjdk.jmh.runner.Runner.internalRun(Runner.java:252) at 
>>> org.openjdk.jmh.runner.Runner.run(Runner.java:208) at 
>>> org.openjdk.jmh.Main.main(Main.java:71) |
>>>
>>> As you can see, there is a problem here, as the META-INF folder does 
>>> not contain the list of benchmarks. This is due to the fact that 
>>> annotations are no longer processed using processors available in 
>>> the classpath. Using JDK 21 to build and run the same pom file works 
>>> fine.
>>>
>>> Adding the following lines to the compiler plugin configuration 
>>> addresses the issue in JDK 22:
>>>
>>> |<compilerArgs> <arg>-proc:full</arg> </compilerArgs> |
>>>
>>> While this is understandable, I?m afraid that not many users will 
>>> have gotten the memo - I don?t seem to get any notes when building 
>>> this project using JDK 21 (probably the notes are swallowed by 
>>> maven?). And, sadly, the lack of a proper JMH plugin means that all 
>>> the JMH poms out there will need some manual tweaking to keep 
>>> working in 22.
>>>
>>> At the very least, I think that JMH?s maven archetype should be 
>>> updated to include the lines above?
>>>
>>> Cheers
>>> Maurizio
>>>
>>> [1] - https://github.com/openjdk/jdk/pull/14432
>>> [2] - https://github.com/openjdk/jmh
>>>
>>> ?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20231031/e31d1f1d/attachment-0001.htm>