Classfile API jdktypes package rename and Signatures move proposal

[Adam Sotona]

From: Brian Goetz <brian.goetz at oracle.com>
Date: Wednesday, 1 March 2023 16:56
To: Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev at openjdk.org <classfile-api-dev at openjdk.org>
Subject: Re: Classfile API jdktypes package rename and Signatures move proposal
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?
Yes, we should integrate “jdk types” before opening Classfile API as preview, because any further package change will affect much larger audience. However JDK-internal Classfile API implementation use and follow-up integrations work should not be blocked by waiting on these.
Isn’t jdk.internal.classfile.java.lang.constant a little bit too long?


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.

Yes, one of the optional plans include putting signatures outside the Classfile library, or maybe to merge it and extend functionality of ClassDesc and MethodTypeDesc.
However we are not there yet, so I take it as “don’t move signatures yet”.

Thanks,
Adam



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.jdktypes package to jdk.internal.classfile.constant to reflect the fact that PackageDesc and ModuleDesc are complementing java.lang.constant package content.
  2.  Move Signature, MethodSignature and ClassSignature from jdk.internal.classfile package 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/20230303/ef9cc5e8/attachment.htm>