Classfile API jdktypes package rename and Signatures move proposal

[Brian Goetz]

Regarding #1, I actually would have thought we'd have integrated the 
"jdk types" into the JDK as RFEs already and they'd be removed by the 
time we integrated the bytecode API, so hadn't given a lot of thought to 
package naming.  If this won't be the case, then we should probably let 
the package name reflect the final resting place, so something like 
jdk.i.c.java.lang.constant?

Assuming that the package will go after upstreaming 
{Module,Package}Desc, I think what you're suggesting is that we will 
eventually put the Signature stuff somewhere outside the bytecode 
library as well?  I think this is a bigger question, which is: for types 
related to quantities in classfiles that are not tied to the bytecode 
library, where should they live?  These include things like descriptor 
parsing and validation (which are duplicated in a dozen places in the 
JDK), signature parsing, conversion between internal and external names, 
etc.




On 3/1/2023 4:24 AM, Adam Sotona wrote:
>
> Hi,
>
> Based on PR feedback I would like to propose two possible API changes:
>
>  1. Rename jdk.internal.classfile.jdktypespackage to
>     jdk.internal.classfile.constantto reflect the fact that
>     PackageDescand ModuleDescare complementing
>     java.lang.constantpackage content.
>  2. Move Signature, MethodSignatureand ClassSignaturefrom
>     jdk.internal.classfilepackage to the same package as #1, as the
>     signature models are similar to descriptor models and serve the
>     same purpose.
>
> Please let me know if you agree or disagree individually with #1 and #2.
>
> Thank you,
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230301/b0aaf25a/attachment-0001.htm>