Jon writes:

There has been some confusion recently about the existence and use of
ClassReader.defineClass. I've long-time felt that ClassReader was
dual-purpose, both managing ClassSymbols, and separately reading .class
files.

Dig a bit deeper and you find the "packages" and "classes" fields are
actually created in and also used in Symtab.

With that in mind, I started wondering why enterPackage and enterClass
are not in Symtab. That seems like a more logical place for them, and
indeed I can see no compelling reason why they should not be there
instead. It is true that the initial completer is ClassReader.complete
but it would be cleaner to have code enter packages and classes in
Symtab, and have a single private reference to ClassReader.complete that
to have so much code accessing ClassReader when they should really be
using Symtab. Indeed, the reference to ClassReader.complete can be done
through a "Symbol.Completer", thus avoiding any static dependence from
Symtab to ClassReader.

(Side note: I think both JavaCompiler and ClassReader should really be
has-a Symbol.Completer, not is-a Symbol.Completer.)

So if we move the enterPackage and enterClass methods to Symtab, then we
can almost completely remove all references to the ClassReader fields
"packages" and "classes". There's some init code that allows you to
create non-definitive ClassReaders, which as best I can tell is
completely unused within LangTools. My recollection is that this feature
was created by Peter Ahe back in JDK 6 days, so I need to do some
archaeology on that one. And, there's a couple of references to classes
in ClassReader.loadClass that could be replaced by new methods on Symtab.

Bottom line, I think this is an interesting area for cleanup that is
worth pursuing at some point.