[External] : Re: Planned features of a classfile context object

[Adam Sotona]

OK,
I’ve updated the PR accordingly:
https://github.com/openjdk/jdk/pull/14180/files
https://github.com/openjdk/jdk/blob/b7e42aa60e8ef6440ffe09577ab2de695dbc7513/src/java.base/share/classes/jdk/internal/classfile/Classfile.java

If there are no objections I’ll proceed to update all doc and snippets to reflect the changes.

Thanks,
Adam

From: liangchenblue at gmail.com <liangchenblue at gmail.com>
Date: Wednesday, 31 May 2023 3:48
To: Brian Goetz <brian.goetz at oracle.com>
Cc: Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev <classfile-api-dev at openjdk.org>
Subject: Re: [External] : Re: Planned features of a classfile context object
I like this withOptions() factory too. Looks more convenient than the
static of() parent-based forking; similar API designs exist in
ModuleLayer, but I think we can just keep the instance version as we
don't have multiple parents for a Classfile.

On Wed, May 31, 2023 at 7:32 AM Brian Goetz <brian.goetz at oracle.com> wrote:
>
> I think having an instance method on Classfile that produces a modified context:
>
>     Classfile withOptions(Option...)
>
> would let you "refine" the options while keeping the base options / cache config / etc.
>
> I agree with Adam that moving all the "make me a class" stuff in one place is a benefit.
>
> On 5/29/2023 3:52 AM, Adam Sotona wrote:
>
>
>
>
>
> From: liangchenblue at gmail.com <liangchenblue at gmail.com>
> Date: Friday, 26 May 2023 23:53
> To: Brian Goetz <brian.goetz at oracle.com>
> Cc: Adam Sotona <adam.sotona at oracle.com>, classfile-api-dev <classfile-api-dev at openjdk.org>
> Subject: [External] : Re: 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.
>
>
>
> I can imagine use for context factory method:
>
> Classfile.Context.of(Classfile.Context parentContext, Option… optionsOverride)
>
> or after merge of Classfile.Context to Classfile:
>
> Classfile.of(Classfile parentContext, Option… optionsOverride)
>
> Is it what you think about?
>
>
>
> 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.
>
> I found the rule of all new classes created from the context only as positive move.
>
> Active class creation directly from ClassModel is very confusing with respect to all the options that must be defined before the model is created.
>
> Explicit call of  cc.transform(classModel, transform) is more clear about what build/transform/write options are applied.
>
>
>
> Thanks,
>
> Adam
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230531/5cd963b3/attachment-0001.htm>