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

[Brian Goetz]

Small nits:
  - should add in buildTo() overload that mirrors build() overloads
  - Not sure doing ClassFileImpl as a record is a win

The rest of it seems nicely minimal.

On 5/31/2023 5:55 AM, Adam Sotona wrote:
>
> OK,
>
> I’ve updated the PR accordingly:
>
> https://github.com/openjdk/jdk/pull/14180/files 
> <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/574abc35/attachment.htm>