Planned features of a classfile context object

[Adam Sotona]

This is a raw prototype of Classfile.Context implementation and the new options:
https://github.com/openjdk/jdk/pull/14180/files
https://github.com/openjdk/jdk/blob/4456ca78bc67138930dc313f71aba58ef1cf5f13/src/java.base/share/classes/jdk/internal/classfile/Classfile.java

It is far from finished, however before going further I would appreciate your comments (mainly on options naming).

Thanks,
Adam


From: Brian Goetz <brian.goetz at oracle.com>
Date: Thursday, 25 May 2023 20:31
To: Adam Sotona <adam.sotona at oracle.com>, liangchenblue at gmail.com <liangchenblue at gmail.com>, classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: Re: Planned features of a classfile context object
A model created within a context can retain a reference to its creating context.  (We do a lot of this sort of thing already, where MethodModel retains a reference to ClassModel, and where CPBuilder retains a reference to Options.)  So for operations that require a context, a model derived from a classfile can use the context that created it.

Methods like parse/build/transform will be moved to the classfile context object.
On 5/25/2023 2:02 PM, Adam Sotona wrote:
I’m trying to figure out how the context will be passed down to the models (if it suppose to be detached from the models).
Do we plan to enforce another CC argument to all models methods requiring context?
Or do we plan to strip down all context-sensitive methods from all models and attach them to a kind of context-wrappers?
For example codeModel.forEach(Classfile.Context.of(…), …) or Classfile.Context.of(…).forEach(codeModel, …) ?

Thanks,
Adam

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