From adam.sotona at oracle.com  Mon Dec  4 11:19:12 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Mon, 4 Dec 2023 11:19:12 +0000
Subject: Class-File API transition to Preview has been integrated
Message-ID: <CY4PR1001MB2150CE89E5F5E0DEF043FD858C86A@CY4PR1001MB2150.namprd10.prod.outlook.com>

Hi,
I would like to inform you that 8308753: Class-File API transition to Preview<https://github.com/openjdk/jdk/pull/15706> has been successfully integrated.

Thank you all for your contribution and collaboration on this important milestone!

Adam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20231204/4762b022/attachment.htm>

From maurizio.cimadamore at oracle.com  Mon Dec  4 11:27:45 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 4 Dec 2023 11:27:45 +0000
Subject: Class-File API transition to Preview has been integrated
In-Reply-To: <CY4PR1001MB2150CE89E5F5E0DEF043FD858C86A@CY4PR1001MB2150.namprd10.prod.outlook.com>
References: <CY4PR1001MB2150CE89E5F5E0DEF043FD858C86A@CY4PR1001MB2150.namprd10.prod.outlook.com>
Message-ID: <2ba2272d-2e62-44bd-b4f3-b9c1fdb0e1e2@oracle.com>

Congratulations and thanks for all the hard work! This is a 
transformational API for the Java ecosystem which I'm sure will yield 
many dividends!

Cheers
Maurizio

On 04/12/2023 11:19, Adam Sotona wrote:
>
> Hi,
>
> I would like to inform you that 8308753: Class-File API transition to 
> Preview <https://github.com/openjdk/jdk/pull/15706>has been 
> successfully integrated.
>
> Thank you all for your contribution and collaboration on this 
> important milestone!
>
> Adam**
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20231204/a9de3467/attachment.htm>

From adam.sotona at oracle.com  Mon Dec  4 11:41:28 2023
From: adam.sotona at oracle.com (Adam Sotona)
Date: Mon, 4 Dec 2023 11:41:28 +0000
Subject: ClassFile API ClassModel::verify is inconsistent with the rest of the
 API
Message-ID: <CY4PR1001MB2150D2FC21F54B7F596C56FF8C86A@CY4PR1001MB2150.namprd10.prod.outlook.com>

Hi,
As a fix of JDK-8321248<https://bugs.openjdk.org/browse/JDK-8321248> I would like to propose following ?last minute? ClassFile API minor change:

PR: https://github.com/openjdk/jdk/pull/16947

ClassFile API ClassModel::verify accepts ClassHierarchyResolver as an optional argument and does not respect ClassFile.ClassHierarchyResolverOption of the actual context.
Parsing, building and transforming take options from the actual ClassFile context and verification should follow the same API pattern.

The proposed patch removes ClassModel::verify methods and introduces new top level methods:
         List<VerifyError> ClassFile::verify(ClassModel model);
         List<VerifyError> ClassFile::verify(byte[] bytes);
         List<VerifyError> ClassFile::verify(Path path);

This bug technically requires a CSR, which is temporary not possible to create.

 Please let me know your comments here or in the PR review.

Thanks,
Adam


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20231204/2fa7c569/attachment-0001.htm>

From liangchenblue at gmail.com  Sun Dec 24 16:11:23 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 24 Dec 2023 10:11:23 -0600
Subject: Using descriptor than internal name hashes for CP ClassEntry
Message-ID: <CABe8uE1XP9VrdCodKY0Hv6WRiCPKVLL9hg0U-AQY7r-=WjWbtg@mail.gmail.com>

Hi,
Since we are using ClassDesc quite often to represent Class constants in
Class-File API, yet it's costly to hash them (as they are internal names in
CP but descriptors in ClassDesc), that Adam has created shortcuts to speed
up fetching of Object CE from CD_Object, I have thought of a new tactic to
hash ClassEntry by full descriptor than by internal name alone.

I have made a prototype at
https://github.com/liachmodded/jdk/commit/2932a560b0029352f1309883b3c5eecfb3d2c771

The idea is that hashing CE as descriptors is easier than creating
substrings for hashing; substring hashing is hard to compute, but appending
and prepending and hash is much easier.

Does this look like a good idea? I only included a test to confirm its
correctness, but haven't got time to bench it against, say, the port of
java.lang,invoke or ProxyGenerator.

Chen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20231224/55e3cc60/attachment.htm>