Planned features of a classfile context object

[Adam Sotona]

I think our current Classfile.Option is already not so far from the proposed global context holder approach.
The most significant use cases to persist (class hierarchy resolution and custom attributes) can be very well cached by keeping the Classfile.Option instances and re-using them as many times as user needs.

var options = List.of(Option.classHierarchyResolver(resolver),
                      Option.attributeMapper(mapper));

Classfile.build(clsDesc, options, handler);
Classfile.parse(bytes, options); //here we have only vararg now

What I’m missing much much more than “global options holder” is per-transformation options (or even option change for transformed method).
For example I would like to use one class model to transform into multiple classes with different options, and I have to write:

Classfile.parse(bytes, options1).transform(classTransform1);
Classfile.parse(bytes, options2).transform(classTransform2);

Instead of simple:
var clm = Classfile.parse(bytes);
clm.transform(classTransform1, options1);
clm.transform(classTransform2, options2);

Or maybe:
var clm = Classfile.parse(bytes, options1);
clm.transform(classTransform1);
clm.setOptions(options2);
clm.transform(classTransform2);

However it raises the main question about what options are really tied to model parsing (I think it is only attributeMapper).
And what options can be safely changed later. For example can I change processDebug, processLineNumbers or processUnknownAttributes on already parsed class model to get different results of the following model traversal?
And there are majority of options unrelated to the parsed class model but affecting only building and transformations (generateStackmap, constantPoolSharing, fixShortJumps, patchDeadCode, classHierarchyResolver, filterDeadLabels).

I think we should make more clear which options affect what actions (parsing, building, transformation) and give more flexibility to change them on the fly.

Thanks,
Adam

From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Brian Goetz <brian.goetz at oracle.com>
Date: Thursday, 18 May 2023 16:16
To: 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
Currently the ConstantPoolBuilder is another place we we attach options.  This was more of a sin of convenience than anything else; the theory was that if we are transforming a class, we'll parse it with a set of options, and then generate a new class which shares its CP, and the options came along for the ride.

Searching for a better name that ClassfileContext.  The name Classfile is too good to waste, but it doesn't represent a classfile (that's ClassModel), so calling the new thing Classfile would likely be weird.  Also ClassfileContext would make it harder to discover the key entry points (build/parse).  Classfile.Context is better in that it is more discoverable at least.

Classfile{Parser,Generator} are more discoverable but only tell half the story, and there's no obvious "first half" of the story.  ClassfileReaderWriter is discoverable and honest but long.  Classfile{Broker,Manager,Mediator} sound like parodies of the Design Patterns era.

A slightly cheeky but possibly viable option is "Classfiles"; while not a collection of classfiles, it is a collection of behaviors _about_ classfiles.

    Classfiles.of(options).parse(bytes)
    Classfiles.of(options).generate(handler)




On 5/17/2023 11:21 AM, Brian Goetz wrote:
These are basically what is on my list, though I had in mind to move _all_ option information to the context, and leave it out of individual processing decisions.
On 5/17/2023 9:59 AM, - wrote:

Hi,

In the discussions a few weeks ago, we envisioned a Classfile context

object shared across multiple Classfile processing scenarios, mainly

for Class hierarchy information caching.



I want to confirm that these are contents of the object, mainly

promoted from individual options:

 - Class Hierarchy information caching

 - Custom attribute processing

 - A set of default options, propagated to individual processing (may

be overridden classfile-wise)



What else is planned for the context object currently? Please don't

hesitate to propose. Thanks!



Chen Liang


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