{@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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  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:  * Provides interfaces describing classfile attributes for the {@link java.lang.classfile} library.

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:  * 
> 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: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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:24:49 GMT, Maurizio Cimadamore  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  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:  * 

> 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:  * 

> 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:  * 
Transformation handling of unknown classfile elements from a future

>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: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>
 
 
 <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
Message-ID: 

On Mon, 2 Oct 2023 13:23:00 GMT, Maurizio Cimadamore  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 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:50:17 GMT, Maurizio Cimadamore  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 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: <-TSw34evJdBqh-rwtz2D0KxhdzD4EaiEMjuYY3MIsMs=.f4c7571b-4e46-421e-a339-070843fbcc3a@github.com>

On Mon, 2 Oct 2023 13:26:38 GMT, Maurizio Cimadamore  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:      *  {@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>
 
 
 <6Kz9mrGKUZxyAkIoS5UzI4KxHauBMYpTKEJjgz6YWVw=.4084b7c7-588f-4ee0-90c6-89c0933b9d1b@github.com>
Message-ID: 

On Mon, 2 Oct 2023 13:29:59 GMT, Maurizio Cimadamore  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  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: 

> 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: 

> 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: 

> 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:40:40 GMT, Maurizio Cimadamore  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  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: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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: 

On Fri, 29 Sep 2023 16:17:06 GMT, Raffaello Giulietti  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 
>
> 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 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 
 - 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 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:40:49 GMT, Maurizio Cimadamore  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:52:58 GMT, Maurizio Cimadamore  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 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 08:34:19 GMT, Adam Sotona  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:56:11 GMT, Maurizio Cimadamore  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 <5ZT-TNRVfEQdEy_6J1g7XZ8mCz49bum71k3V4EjObZQ=.1e138d85-8305-4007-8cfc-6e96158843cc@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 07:18:19 GMT, Adam Sotona  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:45:52 GMT, Maurizio Cimadamore  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: 8315588: JShell does not accept underscore from JEP 443 even
 with --enable-preview
In-Reply-To: 
References: 
Message-ID: 

On Fri, 15 Sep 2023 15:31:43 GMT, Aggelos Biboudis  wrote:

> The current status is that we get an `UNKNOWN` status for those incomplete snippets that involve underscore declaring local variables or patterns. Those should have been classified as `DEFINITELY_INCOMPLETE`. This process takes place in `SourceCodeAnalysisImpl` and `CompletenessAnalyzer` and the processing that takes place regarded `_` as a location of kind `XERR0`. It would be correct now to classify it with `XDECL1`?.

Looks sensible.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15765#pullrequestreview-1652974201

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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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 .class ?

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

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

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: 

> 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:38:18 GMT, Maurizio Cimadamore  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:  * Provides interfaces describing classfile attributes for the {@link java.lang.classfile} library.
> 
> 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:46:53 GMT, Maurizio Cimadamore  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Mon, 2 Oct 2023 17:42:39 GMT, Maurizio Cimadamore  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 
>>  - 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 .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: 

> 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 08:58:55 GMT, Maurizio Cimadamore  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 
>>  - 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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: 

On Mon, 2 Oct 2023 14:47:59 GMT, Aggelos Biboudis  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 
>  - 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 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:50:56 GMT, Maurizio Cimadamore  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: <7gLBfvrwDWY6W3X-ETNeiN5Glv3Ol3ykwjzqNBUVv3c=.f948789b-d2bf-4a8e-ae84-d9c1f58a8207@github.com>

On Mon, 2 Oct 2023 13:57:58 GMT, Maurizio Cimadamore  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:  * 
>> 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: 

> 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 09:58:11 GMT, Maurizio Cimadamore  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 
>>  - 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 13:54:22 GMT, Maurizio Cimadamore  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:  * 

>> 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>
 
 <0CTJUB-_AW4VNsNoglFLvyoabSIgZEESnJCYfm029gE=.818a972c-a5c1-4654-bbcd-117c5a9107aa@github.com>
Message-ID: 

On Mon, 2 Oct 2023 14:03:48 GMT, Maurizio Cimadamore  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: 

> 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Mon, 2 Oct 2023 14:51:47 GMT, Maurizio Cimadamore  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
Message-ID: <-L0VbUtNh5kdKGoUdONyiIF2RjKislGhtUcoF7ACONI=.8b7b9a17-4659-49ed-9ea9-dce41381a7b5@github.com>

On Tue, 3 Oct 2023 13:19:18 GMT, Aggelos Biboudis  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 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: <2l3nPeHsaRxgmPSihVa2engMW0eMBBqqAK4HBJbfV6k=.5733dff5-ac59-4c55-8b26-32eff1f0fefe@github.com>

On Tue, 3 Oct 2023 14:11:08 GMT, Adam Sotona  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 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: 

> 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>
 
 <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  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: 

> 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: 

> 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 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: 

> 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 09:13:30 GMT, Maurizio Cimadamore  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 
>>  - 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: 

> 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>

On Tue, 3 Oct 2023 09:08:31 GMT, Maurizio Cimadamore  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 
>>  - 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 jlahoda at openjdk.org  Wed Oct  4 18:34:35 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 4 Oct 2023 18:34:35 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine
In-Reply-To: 
References: 
Message-ID: 

On Wed, 16 Aug 2023 14:55:54 GMT, Archie Cobbs  wrote:

> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
> 
> **Background**
> 
> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
> 
> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
> 
> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
> 
> **Issue 1**
> 
> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
> 
> **Issue 2**
> 
> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
> 
> However, the "local" execution engine ignores the remote VM options.
> 
> Here's a simple demonstration:
> 
> 
>     $ ls classes/test/Foo.class
>     classes/test/Foo.class
>     $ jshell --execution=local --class-path classes
>     |  Welcome to JShell -- Version 20.0.1
>     |  For an introduction type: /help intro
> 
>     jshell> Class.forName("test.Foo");
>     |  Exception java.lang.ClassNotFoundException: test.Foo
>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>     |        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
>     |        at ...

I apologize to belated answer.

So, it seems to me that there are only two problems:
1. `--class-path` is not reflected. That clearly should be fixed
2. the underlying `ClassLoader` cannot be set easily

For 2., there appear to be three new pieces of API to do that: 
- making `DefaultLoaderDelegate` public, and adding a constructor accepting the base `ClassLoader` to it.
- adding a new constructor to `LocalExecutionControl`, accepting the base `ClassLoader`
- adding ability to use `Thread`'s context `ClassLoader`

Having three different APIs that only avoid implementing custom `LoaderDelegate` seems a bit excessive to me, unless there's a strong reason for them. I would suggest to settle on one way, and delete the others. Offhand, my preference order would be:
- new `LocalExecutionControl` constructor (it is the smallest API surface, so as long as it solves the problem, it seems like the obvious solution)
- making `DefaultLoaderDelegate` public (the behavioral compatibility we might need to keep could be non-trivial)
- using context CL (I don't quite see the benefit of this, if we can add satisfactory real API, and the API surface seems pretty big, so we are not really saving anything)

Also, each new API element needs to be marked with `@since 22`, and covered by the corresponding CSR.

test/langtools/jdk/jshell/LocalExecutionTestSupport.java line 38:

> 36: 
> 37:     /*
> 38:      * This is a classfile corresponding to this source:

Compiling classes in the test is actually usually easier than inlining the bytecode in the test. One can use the `@compile` tag (which may not be ideal here), or `java.util.spi.ToolProvider` with tool `javac` (that can only compile sources on disk to classfiles on disk, but that would still be OK here), or `javax.tools.ToolProvider` (which allows to compile in memory, full or partial), or the `test/langtools/tools/lib/toolbox/ToolBox.java`. Given the context here, `java.util.spi.ToolProvider` might give good results without embedding bytecode in the test.

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

PR Review: https://git.openjdk.org/jdk/pull/15311#pullrequestreview-1658225733
PR Review Comment: https://git.openjdk.org/jdk/pull/15311#discussion_r1346280835

From acobbs at openjdk.org  Wed Oct  4 20:54:13 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Oct 2023 20:54:13 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 4 Oct 2023 18:32:11 GMT, Jan Lahoda  wrote:

> Having three different APIs that only avoid implementing custom `LoaderDelegate` seems a bit excessive to me, unless there's a strong reason for them. I would suggest to settle on one way, and delete the others. Offhand, my preference order would be:
> 
>     * new `LocalExecutionControl` constructor (it is the smallest API surface, so as long as it solves the problem, it seems like the obvious solution)
> 
>     * making `DefaultLoaderDelegate` public (the behavioral compatibility we might need to keep could be non-trivial)
> 
>     * using context CL (I don't quite see the benefit of this, if we can add satisfactory real API, and the API surface seems pretty big, so we are not really saving anything)

I agree it makes sense to keep the API changes minimal. The problem is that the `--class-path` fix entails adding the path components to whatever `LoaderDelegate` you are using via `addToClasspath()`, so the two problems we're trying to solve intersect.

In other words, consider your first option:
* It requires you to write your own `ExecutionControlProvider`
* The fix for the `--class-path` bug is part of `LocalContextExecutionControlProvider`
* There currently no way to subclass `LocalContextExecutionControlProvider` and also inherit that fix

So you're stuck with choosing between being able to supply a parent `ClassLoader` or having the `--class-path` bug fixed, but not both (or duplicating the bug fix in your own implementation).

Here's another way it could work:

* Start with your first option, i.e., add the new `LocalExecutionControl` constructor
* Making these two new methods in the patch for `LocalExecutionControlProvider` protected and therefore overriddable by subclasses:
  * `createLoaderDelegate()`
  * `createExecutionControl()`

Of course that also adds API surface.

An alternative could be encapsulating the bug fix in its own static method in `LocalExecutionControlProvider`:

public static void applyRemoteVMOptions(ExecutionEnv env, LoaderDelegate delegate) { ... }

or even as a default method in `LoaderDelegate`:

default void initialize(ExecutionEnv env, Map parameters) { ... }

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

PR Comment: https://git.openjdk.org/jdk/pull/15311#issuecomment-1747621514

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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona  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 acobbs at openjdk.org  Wed Oct  4 22:19:27 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Oct 2023 22:19:27 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v2]
In-Reply-To: 
References: 
Message-ID: <4qoKWRWzj8wBtBNmPgL2yb7eJCJVOoVT62djscW_-cc=.4d9a0e48-dc69-4c56-9219-4fb5e83cf3d7@github.com>

> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
> 
> **Background**
> 
> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
> 
> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
> 
> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
> 
> **Issue 1**
> 
> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
> 
> **Issue 2**
> 
> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
> 
> However, the "local" execution engine ignores the remote VM options.
> 
> Here's a simple demonstration:
> 
> 
>     $ ls classes/test/Foo.class
>     classes/test/Foo.class
>     $ jshell --execution=local --class-path classes
>     |  Welcome to JShell -- Version 20.0.1
>     |  For an introduction type: /help intro
> 
>     jshell> Class.forName("test.Foo");
>     |  Exception java.lang.ClassNotFoundException: test.Foo
>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>     |        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
>     |        at ...

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 seven additional commits since the last revision:

 - Update tests to compile source instead of including bytecode.
 - Merge branch 'master' into JShellStuff
 - Make the DefaultLoaderDelegate class public.
 - Apply the "--class-path" flag to the "local" execution engine.
 - Add new "contextLoaderParent" parameter for LocalExecutionControlProvider.
 - Allow specifying a parent class loader when creating a LocalExecutionControl.
 - Allow specifying a parent class loader when creating a DefaultLoaderDelegate.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15311/files
  - new: https://git.openjdk.org/jdk/pull/15311/files/1e3c5140..50bb7612

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

  Stats: 135560 lines in 3803 files changed: 64113 ins; 27176 del; 44271 mod
  Patch: https://git.openjdk.org/jdk/pull/15311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15311/head:pull/15311

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

From acobbs at openjdk.org  Wed Oct  4 22:19:29 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 4 Oct 2023 22:19:29 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 4 Oct 2023 18:15:13 GMT, Jan Lahoda  wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Update tests to compile source instead of including bytecode.
>>  - Merge branch 'master' into JShellStuff
>>  - Make the DefaultLoaderDelegate class public.
>>  - Apply the "--class-path" flag to the "local" execution engine.
>>  - Add new "contextLoaderParent" parameter for LocalExecutionControlProvider.
>>  - Allow specifying a parent class loader when creating a LocalExecutionControl.
>>  - Allow specifying a parent class loader when creating a DefaultLoaderDelegate.
>
> test/langtools/jdk/jshell/LocalExecutionTestSupport.java line 38:
> 
>> 36: 
>> 37:     /*
>> 38:      * This is a classfile corresponding to this source:
> 
> Compiling classes in the test is actually usually easier than inlining the bytecode in the test. One can use the `@compile` tag (which may not be ideal here), or `java.util.spi.ToolProvider` with tool `javac` (that can only compile sources on disk to classfiles on disk, but that would still be OK here), or `javax.tools.ToolProvider` (which allows to compile in memory, full or partial), or the `test/langtools/tools/lib/toolbox/ToolBox.java`. Given the context here, `java.util.spi.ToolProvider` might give good results without embedding bytecode in the test.

Thanks - fixed in 50bb7612c16.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15311#discussion_r1346531329

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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 4 Oct 2023 09:30:16 GMT, Adam Sotona  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: 

> 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: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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
Message-ID: <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>

On Tue, 3 Oct 2023 09:05:17 GMT, Maurizio Cimadamore  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 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
Message-ID: 

On Tue, 3 Oct 2023 08:54:57 GMT, Maurizio Cimadamore  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 
>>  - 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 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 08:20:58 GMT, Aggelos Biboudis  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: 

> 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@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  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 duke at openjdk.org  Thu Oct  5 12:13:39 2023
From: duke at openjdk.org (Michal Sobierski)
Date: Thu, 5 Oct 2023 12:13:39 GMT
Subject: RFR: 8312475: org.jline.util.PumpReader signed byte problem
Message-ID: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>

Added casting to `& 0xFF` to the InputStream read method return value.

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

Commit messages:
 - 8312475: org.jline.util.PumpReader signed byte problem

Changes: https://git.openjdk.org/jdk/pull/16053/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16053&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8312475
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/16053.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16053/head:pull/16053

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

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: 

> 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>
 
 
 <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@github.com>
Message-ID: 

On Thu, 5 Oct 2023 08:14:53 GMT, Aggelos Biboudis  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: 

> 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: 

> 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 acobbs at openjdk.org  Thu Oct  5 18:52:07 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Oct 2023 18:52:07 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v2]
In-Reply-To: 
References: 
 
Message-ID: 

On Wed, 4 Oct 2023 18:32:11 GMT, Jan Lahoda  wrote:

>> 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 seven additional commits since the last revision:
>> 
>>  - Update tests to compile source instead of including bytecode.
>>  - Merge branch 'master' into JShellStuff
>>  - Make the DefaultLoaderDelegate class public.
>>  - Apply the "--class-path" flag to the "local" execution engine.
>>  - Add new "contextLoaderParent" parameter for LocalExecutionControlProvider.
>>  - Allow specifying a parent class loader when creating a LocalExecutionControl.
>>  - Allow specifying a parent class loader when creating a DefaultLoaderDelegate.
>
> I apologize to belated answer.
> 
> So, it seems to me that there are only two problems:
> 1. `--class-path` is not reflected. That clearly should be fixed
> 2. the underlying `ClassLoader` cannot be set easily
> 
> For 2., there appear to be three new pieces of API to do that: 
> - making `DefaultLoaderDelegate` public, and adding a constructor accepting the base `ClassLoader` to it.
> - adding a new constructor to `LocalExecutionControl`, accepting the base `ClassLoader`
> - adding ability to use `Thread`'s context `ClassLoader`
> 
> Having three different APIs that only avoid implementing custom `LoaderDelegate` seems a bit excessive to me, unless there's a strong reason for them. I would suggest to settle on one way, and delete the others. Offhand, my preference order would be:
> - new `LocalExecutionControl` constructor (it is the smallest API surface, so as long as it solves the problem, it seems like the obvious solution)
> - making `DefaultLoaderDelegate` public (the behavioral compatibility we might need to keep could be non-trivial)
> - using context CL (I don't quite see the benefit of this, if we can add satisfactory real API, and the API surface seems pretty big, so we are not really saving anything)
> 
> Also, each new API element needs to be marked with `@since 22`, and covered by the corresponding CSR.

@lahodaj any opinions on the best way to proceed? Thanks for taking the time to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15311#issuecomment-1749461625

From jlahoda at openjdk.org  Thu Oct  5 19:12:05 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 5 Oct 2023 19:12:05 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v2]
In-Reply-To: <4qoKWRWzj8wBtBNmPgL2yb7eJCJVOoVT62djscW_-cc=.4d9a0e48-dc69-4c56-9219-4fb5e83cf3d7@github.com>
References: 
 <4qoKWRWzj8wBtBNmPgL2yb7eJCJVOoVT62djscW_-cc=.4d9a0e48-dc69-4c56-9219-4fb5e83cf3d7@github.com>
Message-ID: 

On Wed, 4 Oct 2023 22:19:27 GMT, Archie Cobbs  wrote:

>> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
>> 
>> **Background**
>> 
>> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
>> 
>> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
>> 
>> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
>> 
>> **Issue 1**
>> 
>> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
>> 
>> **Issue 2**
>> 
>> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
>> 
>> However, the "local" execution engine ignores the remote VM options.
>> 
>> Here's a simple demonstration:
>> 
>> 
>>     $ ls classes/test/Foo.class
>>     classes/test/Foo.class
>>     $ jshell --execution=local --class-path classes
>>     |  Welcome to JShell -- Version 20.0.1
>>     |  For an introduction type: /help intro
>> 
>>     jshell> Class.forName("test.Foo");
>>     |  Exception java.lang.ClassNotFoundException: test.Foo
>>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>>     |        at DefaultLoaderDelegate$RemoteClass...
>
> 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 seven additional commits since the last revision:
> 
>  - Update tests to compile source instead of including bytecode.
>  - Merge branch 'master' into JShellStuff
>  - Make the DefaultLoaderDelegate class public.
>  - Apply the "--class-path" flag to the "local" execution engine.
>  - Add new "contextLoaderParent" parameter for LocalExecutionControlProvider.
>  - Allow specifying a parent class loader when creating a LocalExecutionControl.
>  - Allow specifying a parent class loader when creating a DefaultLoaderDelegate.

Seems adding `createExecutionControl()` to `LocalExecutionControlProvider` should be enough? Something along these lines possibly?

diff --git a/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControlProvider.java b/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControlProvider.java
index cc3879c5c6d..370fbb6bdfd 100644
--- a/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControlProvider.java
+++ b/src/jdk.jshell/share/classes/jdk/jshell/execution/LocalExecutionControlProvider.java
@@ -25,6 +25,7 @@
 
 package jdk.jshell.execution;
 
+import java.util.List;
 import java.util.Map;
 import jdk.jshell.spi.ExecutionControl;
 import jdk.jshell.spi.ExecutionControlProvider;
@@ -78,7 +79,31 @@ public Map defaultParameters() {
      */
     @Override
     public ExecutionControl generate(ExecutionEnv env, Map parameters) {
-        return new LocalExecutionControl();
+        ExecutionControl result = createExecutionControl(env, parameters);
+
+        // Apply any configured class path
+        List remoteOptions = env.extraRemoteVMOptions();
+        int classPathIndex = remoteOptions.indexOf("--class-path") + 1;
+        if (classPathIndex > 0 && classPathIndex < remoteOptions.size()) {
+            try {
+                result.addToClasspath(remoteOptions.get(classPathIndex));
+            } catch (ExecutionControl.ExecutionControlException e) {
+                throw new RuntimeException("error configuring class path", e);
+            }
+        }
+
+        return result;
     }
 
+    /**
+     * Create the {@link ExecutionControl} using the specified delegate.
+     * Called from {@link #generate(ExecutionEnv, Map) }.
+     *
+     * @param env the {@code ExecutionEnv} for which the ExecutionControl should be created
+     * @param parameters the parameters that were passed to {@code generate}
+     * @return the newly created {@code ExecutionControl}
+     */
+    public ExecutionControl createExecutionControl(ExecutionEnv env, Map parameters) {
+        return new LocalExecutionControl(new DefaultLoaderDelegate());
+    }
 }

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

PR Comment: https://git.openjdk.org/jdk/pull/15311#issuecomment-1749491932

From acobbs at openjdk.org  Thu Oct  5 22:36:36 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Oct 2023 22:36:36 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v3]
In-Reply-To: 
References: 
Message-ID: 

> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
> 
> **Background**
> 
> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
> 
> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
> 
> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
> 
> **Issue 1**
> 
> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
> 
> **Issue 2**
> 
> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
> 
> However, the "local" execution engine ignores the remote VM options.
> 
> Here's a simple demonstration:
> 
> 
>     $ ls classes/test/Foo.class
>     classes/test/Foo.class
>     $ jshell --execution=local --class-path classes
>     |  Welcome to JShell -- Version 20.0.1
>     |  For an introduction type: /help intro
> 
>     jshell> Class.forName("test.Foo");
>     |  Exception java.lang.ClassNotFoundException: test.Foo
>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>     |        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
>     |        at ...

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

  Narrow the API changes to adding just one additional method.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15311/files
  - new: https://git.openjdk.org/jdk/pull/15311/files/50bb7612..cab048a8

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

  Stats: 87 lines in 4 files changed: 40 ins; 24 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/15311.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15311/head:pull/15311

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

From acobbs at openjdk.org  Thu Oct  5 22:36:36 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Oct 2023 22:36:36 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v2]
In-Reply-To: 
References: 
 <4qoKWRWzj8wBtBNmPgL2yb7eJCJVOoVT62djscW_-cc=.4d9a0e48-dc69-4c56-9219-4fb5e83cf3d7@github.com>
 
Message-ID: 

On Thu, 5 Oct 2023 19:09:09 GMT, Jan Lahoda  wrote:

> Seems adding createExecutionControl() to LocalExecutionControlProvider should be enough? Something along these lines possibly?

Ah yes, that would work... because `DirectExecutionControl.addToClasspath()` invokes `LoaderDelegate.addToClasspath()`.

It's better place to apply the class path at that higher level anyway.

Thanks! I've applied this in cab048a87a3 ... let me know what you think.

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

PR Comment: https://git.openjdk.org/jdk/pull/15311#issuecomment-1749744538

From acobbs at openjdk.org  Thu Oct  5 23:08:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 5 Oct 2023 23:08:57 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v4]
In-Reply-To: 
References: 
Message-ID: 

> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
> 
> **Background**
> 
> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
> 
> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
> 
> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
> 
> **Issue 1**
> 
> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
> 
> **Issue 2**
> 
> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
> 
> However, the "local" execution engine ignores the remote VM options.
> 
> Here's a simple demonstration:
> 
> 
>     $ ls classes/test/Foo.class
>     classes/test/Foo.class
>     $ jshell --execution=local --class-path classes
>     |  Welcome to JShell -- Version 20.0.1
>     |  For an introduction type: /help intro
> 
>     jshell> Class.forName("test.Foo");
>     |  Exception java.lang.ClassNotFoundException: test.Foo
>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>     |        at DefaultLoaderDelegate$RemoteClassLoader.findClass (DefaultLoaderDelegate.java:154)
>     |        at ...

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

  Add missing @param and @since tags for new constructor.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15311/files
  - new: https://git.openjdk.org/jdk/pull/15311/files/cab048a8..03565459

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

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

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

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: 

> 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <6dJOqkrxMiYdXor-HEaNVNoiNvCsXi1BpA8w0QzfEp8=.e7499f70-46be-44df-b198-977ae137e78c@github.com>
 
 
 <-OaXxwydpWoCxxdrioRb--za1NLRUGvxbasBlGcf07E=.3b45c8fd-8282-48ff-a52b-ba0f5cf3d7b2@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  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>
 
 <8MevNyryZdtgfndhK_ASX5NGLaXesVGfJ89iSLYJyzg=.cd11e37d-bba0-4d02-a044-addb706f6852@github.com>
Message-ID: 

On Wed, 4 Oct 2023 10:08:31 GMT, Aggelos Biboudis  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: 

> 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 shade at openjdk.org  Fri Oct  6 12:48:33 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 6 Oct 2023 12:48:33 GMT
Subject: RFR: 8312475: org.jline.util.PumpReader signed byte problem
In-Reply-To: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
References: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
Message-ID: 

On Thu, 5 Oct 2023 12:06:12 GMT, Michal Sobierski  wrote:

> Added casting to `& 0xFF` to the InputStream read method return value.

@lahodaj, what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/16053#issuecomment-1750609114

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: 

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: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 23:39:27 GMT, Jonathan Gibbons  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 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: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 23:39:27 GMT, Jonathan Gibbons  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: 

> 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: 

> 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: 
References: 
Message-ID: 

On Fri, 6 Oct 2023 23:39:27 GMT, Jonathan Gibbons  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 
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: 

> 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 
  Co-authored-by: Angelos Bimpoudis 

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

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 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 
   Co-authored-by: Angelos Bimpoudis 
 - 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 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 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: 

> 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 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: 

On Tue, 10 Oct 2023 11:29:40 GMT, Adam Sotona  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 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: 

> 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 <4aHN-jhUSSm_w8HguRuJ4gPhOJK7ejnH53fVaEAAusg=.c15c43fb-5142-4c85-a15d-a35674f2b3b5@github.com>
 
Message-ID: 

On Tue, 10 Oct 2023 14:46:32 GMT, Chen Liang  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: 

> 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 
   Co-authored-by: Angelos Bimpoudis 
 - 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 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: 

> 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 jlahoda at openjdk.org  Wed Oct 11 20:53:14 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 11 Oct 2023 20:53:14 GMT
Subject: RFR: 8314327: Issues with JShell when using "local" execution
 engine [v4]
In-Reply-To: 
References: 
 
Message-ID: 

On Thu, 5 Oct 2023 23:08:57 GMT, Archie Cobbs  wrote:

>> There are a few bugs (or "opportunities for improvement") in JShell's support for "local" execution control.
>> 
>> **Background**
>> 
>> JShell utilizes two distinct "class lookup" functions. First, it looks up clases when compiling snippets. This happens indirectly via the Java compiler using its `JavaFileSystem` interface. Secondly, JShell executes code by supplying an execution engine with class files and asking it to invoke methods. The execution engine therefore performs a class lookup function when it links and loads these classes. The compilation happens on the local machine while the execution happens either locally or remotely.
>> 
>> For everything to run smoothly, both of these lookup functions must be working for whatever class(es) you want to name in JShell input.
>> 
>> Local execution is implemented by `LocalExecutionControl` and provided by the `LocalExecutionControlProvider` under the name `"local"`. In turn, `LocalExecutionControl` uses a `LoaderDelegate` to manage class loading. The default `DefaultLoaderDelegate` uses a custom subclass of `URLClassLoader` (called `RemoteClassLoader`). This class loader has two functions: (a) keep track of snippet classes generated by JShell, and (b) find classes for the execution engine (normal class loader function).
>> 
>> **Issue 1**
>> 
>> The `RemoteClassLoader` is hard-wired with the system class loader as its parent loader. This means that in non-trivial class loading scenarios, such as when running in web servlet container, the application's classes are not visible to the local execution engine.  As a result, it's impossible to resolve any of these classes.
>> 
>> **Issue 2**
>> 
>> JShell has a `--class-path` parameter that is supposed to handle properly configuring *both* lookup functions, i.e., compilation and execution. Internally, this is done by (a) configuring the compiler's class path, and (b) passing this flag to the execution engine as a "remove VM option".
>> 
>> However, the "local" execution engine ignores the remote VM options.
>> 
>> Here's a simple demonstration:
>> 
>> 
>>     $ ls classes/test/Foo.class
>>     classes/test/Foo.class
>>     $ jshell --execution=local --class-path classes
>>     |  Welcome to JShell -- Version 20.0.1
>>     |  For an introduction type: /help intro
>> 
>>     jshell> Class.forName("test.Foo");
>>     |  Exception java.lang.ClassNotFoundException: test.Foo
>>     |        at URLClassLoader.findClass (URLClassLoader.java:445)
>>     |        at DefaultLoaderDelegate$RemoteClass...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing @param and @since tags for new constructor.

Looks reasonable to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15311#pullrequestreview-1672565411

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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 07:17:04 GMT, Adam Sotona  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@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  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>
 
 
 <0g69xIyi7-edOQ35XZBQhNazpZKiDSouTo2SJ0zNOAU=.4d70694f-d75e-4347-bb3d-00a2efab680a@github.com>
Message-ID: 

On Thu, 12 Oct 2023 10:40:03 GMT, Adam Sotona  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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 07:17:04 GMT, Adam Sotona  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:  * 

> 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:  * 

> 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:  * 
Transformation handling of unknown classfile elements
> 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: 

> 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: 
References: <5IwVpRwPx8HQfqUqzhtpPP3yBUI3xvvzWHThG1OxYYA=.ea599d4e-5052-4c61-b12e-3ad6604fbb12@github.com>
 
 
Message-ID: 

On Thu, 12 Oct 2023 11:11:10 GMT, Maurizio Cimadamore  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:  * 
>> 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:  * 

>> 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:  * 
Transformation handling of unknown classfile elements
>> 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 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  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 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@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  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  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: <-7dHm7aTGSEtcaNvl1RNNz2hgAbSVT6ljg-h9yRaMPc=.d1dafc1b-4828-497f-8c62-595060213a3f@github.com>

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Wed, 11 Oct 2023 15:43:19 GMT, Aggelos Biboudis  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 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: 

> 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 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: 

> 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 
   Co-authored-by: Angelos Bimpoudis 
 - 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@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  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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
 
Message-ID: 

On Thu, 12 Oct 2023 20:42:50 GMT, Vicente Romero  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 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 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: 

On Mon, 16 Oct 2023 19:16:41 GMT, Aggelos Biboudis  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 13:00:15 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 17 Oct 2023 13:00:15 GMT
Subject: Integrated: 8315588: JShell does not accept underscore from JEP 443
 even with --enable-preview
In-Reply-To: 
References: 
Message-ID: <3yNuAPiZSCg0omtHTTjJRPPevkOPPi9Xx2StK-u8TJE=.260570e7-24bc-4151-a302-70774f9b1312@github.com>

On Fri, 15 Sep 2023 15:31:43 GMT, Aggelos Biboudis  wrote:

> The current status is that we get an `UNKNOWN` status for those incomplete snippets that involve underscore declaring local variables or patterns. Those should have been classified as `DEFINITELY_INCOMPLETE`. This process takes place in `SourceCodeAnalysisImpl` and `CompletenessAnalyzer` and the processing that takes place regarded `_` as a location of kind `XERR0`. It would be correct now to classify it with `XDECL1`?.

This pull request has now been integrated.

Changeset: 2bf1863e
Author:    Aggelos Biboudis 
Committer: Jan Lahoda 
URL:       https://git.openjdk.org/jdk/commit/2bf1863e24c8842e3ddbdacda54e412023951983
Stats:     80 lines in 2 files changed: 78 ins; 0 del; 2 mod

8315588: JShell does not accept underscore from JEP 443 even with --enable-preview

Reviewed-by: jlahoda

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

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

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: 

> 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 

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

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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 <8yU_xOd6jajN9pJ2Hjvs-ye4BV2hbnMlyVmxP_CqL-0=.08fab3e6-4cd1-4f72-801e-2c2d2210ce9e@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 12:06:53 GMT, Raffaello Giulietti  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 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: 
References: <4GCkSMggtYI8KnM-kELHez3Nd42WIrfd6jOF1bbK5PA=.12aec6f3-669b-4675-ad34-ffe28cb23459@github.com>
 
Message-ID: 

On Tue, 17 Oct 2023 14:44:38 GMT, Aggelos Biboudis  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 

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: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 
 - 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 
   Co-authored-by: Angelos Bimpoudis 
 - ... 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 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 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: 

> 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 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: 

> 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 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: 
References: 
Message-ID: 

> 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 #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 shade at openjdk.org  Mon Oct 23 09:06:29 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Oct 2023 09:06:29 GMT
Subject: RFR: 8312475: org.jline.util.PumpReader signed byte problem
In-Reply-To: 
References: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
 
Message-ID: 

On Fri, 6 Oct 2023 12:45:50 GMT, Aleksey Shipilev  wrote:

> @lahodaj, what do you think?

Ping @lahodaj again :)

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

PR Comment: https://git.openjdk.org/jdk/pull/16053#issuecomment-1774742783

From shade at openjdk.org  Mon Oct 23 09:09:38 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 23 Oct 2023 09:09:38 GMT
Subject: RFR: 8312475: org.jline.util.PumpReader signed byte problem
In-Reply-To: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
References: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
Message-ID: 

On Thu, 5 Oct 2023 12:06:12 GMT, Michal Sobierski  wrote:

> Added casting to `& 0xFF` to the InputStream read method return value.

I am providing a second review anyway.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16053#pullrequestreview-1692055346

From jlahoda at openjdk.org  Mon Oct 23 10:57:37 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 23 Oct 2023 10:57:37 GMT
Subject: RFR: 8312475: org.jline.util.PumpReader signed byte problem
In-Reply-To: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
References: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
Message-ID: 

On Thu, 5 Oct 2023 12:06:12 GMT, Michal Sobierski  wrote:

> Added casting to `& 0xFF` to the InputStream read method return value.

Makes sense - has this been reported upstream yet? Alternatively, `Byte.toUnsignedInt` could be used.

In any case, I suspect this class is not used in the JDK, so I don't expect any impact from this.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16053#pullrequestreview-1692250749

From duke at openjdk.org  Mon Oct 23 14:34:42 2023
From: duke at openjdk.org (Michal Sobierski)
Date: Mon, 23 Oct 2023 14:34:42 GMT
Subject: Integrated: 8312475: org.jline.util.PumpReader signed byte problem
In-Reply-To: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
References: <3zSM2WD4yAvyk0pC6m4zBcQxAESQDMuUgMejtk8n_vw=.6636f2d6-ece1-4b01-b267-ae8ab1eec584@github.com>
Message-ID: <8w3y8LAuKTMW9N8KavKrtgO97rphv3EDnzbvzAIHYhw=.b3e469f4-8e10-4b27-be3c-533d73ed0b79@github.com>

On Thu, 5 Oct 2023 12:06:12 GMT, Michal Sobierski  wrote:

> Added casting to `& 0xFF` to the InputStream read method return value.

This pull request has now been integrated.

Changeset: bea2d486
Author:    Michal Sobierski 
Committer: Aleksey Shipilev 
URL:       https://git.openjdk.org/jdk/commit/bea2d48696ee2c213e475ca3aa3aa9c412b91089
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8312475: org.jline.util.PumpReader signed byte problem

Reviewed-by: shade, jlahoda

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

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

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 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: 

> 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 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 
 - 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

