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

Adam Sotona adam.sotona at oracle.com
Mon May 29 07:52:21 UTC 2023



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/20230529/d059b8c9/attachment-0001.htm>


More information about the classfile-api-dev mailing list