Planned features of a classfile context object

[-]

The Classfile context in the patch looks somewhat like a Classfile
element to me :) With that in mind, I wish we can allow users to
transform/fork these immutable contexts, such as skipping line numbers
for particular files, skip constantpool sharing for select
transformations, etc. with the same code pattern in Classfile
Transformers. Of course, a transformation will always read the default
values of options if not explicitly set, and the transformed context
will have dropped options replaced with their default values.

In addition, ClassModel.transform can probably be kept, which means
using the creation context of the ClassModel to transform this model,
if we make it clear that all models have their lifetime bound to a
Classfile object.

On Fri, May 26, 2023 at 4:16 PM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> Some review comments on your patch:
>
>  - I'd prefer for all of the static methods in Classfile to go away, though I can imagine choosing to leave the most basic version (no options) of build/parse around as conveniences.  If we leave these, the Javadoc should make it clear that these are equivalent to Context.of().parse(...).
>  - I am OK with calling the context class "Classfile" for the time being; this makes the diff easier to follow as it makes it clear that the static methods are being promoted to instance methods, and we can discuss name later.
>  - I see you cache the Options in BufWriterImpl/BufferedCodeBuilder/etc, but we should probably be caching the full context (impl) object instead, and fetching options out of the context.
>  - (Syntax nit) Some enum options are fully descriptive of what they are (DROP_DEBUG_ELEMENTS), and some are implicit (ALWAYS_GENERATE -- generate what?).  I think I would prefer to err on the side of fully descriptive (and people can use static imports to drop the qualifier if they like), but we should be consistent.  There should be a convention of what the default is (like "first is always default") for options that are enums.
>
>
> On 5/26/2023 11:18 AM, Adam Sotona wrote:
>
> 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
>
>
>
>