[External] : Re: ClassHierarchyResolver using Reflection information

[Brian Goetz]

Thinking a little more ... if we do this:

On 3/20/2023 2:19 PM, Brian Goetz wrote:
>
> Stepping back, the global cache suggests that we might want to 
> refactor the front-door entry point to the API.  Right now, we have a 
> pile of static methods in Classfile (build/parse), many of which take 
> sets of options.  The point of the global cache is to avoid 
> re-resolving information every time, but the global granularity is 
> questionable -- it seems much more likely that an agent would want to 
> create a static per-agent configuration, shared across uses of that 
> agent, but not shared with other agents.  This suggests that perhaps 
> the methods on Classfile really should be instance methods on an 
> object that encapsulates the option set as well as accumulating cache 
> state.  (And if the agent is unloaded, all the cache goes with it.)
>
> Something like:
>
>     public class ClassfileReaderWriterThingie {
>         public ClassfileReaderWriterThingie(Option... options) { ... }
>
>         public ClassModel parse(byte[] bs) { ... }
>         public ClassModel parse(Path p) { ... }
>
>         public byte[] build(ClassDesc thisClass, Consumer<CB> handler) 
> { ... }
>         // drop overload taking options, since its in the ctor
>         public byte[] build(ClassEntry thisClassEntry, CPB cpBuilder, 
> Consumer<CB> handler) { ... }
>
>         // buildTo and buildModule overloads
>     }

then we can completely eliminate the static "default" resolver (with 
attendant cache), and the act of creating a ClassfileRWT should (if no 
resolver option is selected) create a cached resolver _for that CRWT_.  
This completely eliminates the shared static cache, which will surely 
come back to bite us, without making it any more difficult for users.

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