<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">Thinking a little more ... if
        we do this:</font></font><br>
    <br>
    <div class="moz-cite-prefix">On 3/20/2023 2:19 PM, Brian Goetz
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:d5144938-747b-7cde-cee1-3a51218518c2@oracle.com"><font size="4"><font face="monospace"><br>
          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.)  <br>
          <br>
          Something like:<br>
          <br>
              public class ClassfileReaderWriterThingie { <br>
                  public ClassfileReaderWriterThingie(Option... options)
          { ... }<br>
          <br>
        </font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace">        public ClassModel
              parse(byte[] bs) { ... }<br>
            </font></font></font></font><font size="4"><font face="monospace"><font size="4"><font face="monospace"><font size="4"><font face="monospace">        public
                  ClassModel parse(Path p) { ... }<br>
                  <br>
                          public byte[] build(ClassDesc thisClass,
                  Consumer<CB> handler) { ... }<br>
                          // drop overload taking options, since its in
                  the ctor<br>
                          public byte[] build(ClassEntry thisClassEntry,
                  CPB cpBuilder, Consumer<CB> handler) { ... }<br>
                  <br>
                          // buildTo and buildModule overloads<br>
                      }</font></font></font></font></font></font></blockquote>
    <br>
    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.<br>
    <br>
    <br>
  </body>
</html>