The current logic for reading and writing constant pool entries suffers from several issues:

1) When writing, pool constants are added to the pool through an interface which accepts any Object; the relationship between javac entities and constant pool entries is obscure and hidden in the source.

2) When writing, it is sometime possible to end up with duplicate entries, because of the way javac entities are mapped onto the pool. Several attempts have been made to fix this issue in the past; while the current state is much better than what it was e.g. in JDK 7, the architecture is still far from preventing duplicates by design.

3) The absence of any real pool abstraction/API makes clients, such as ClassReader and ClassWriter responsible for reading/writing pool entries themselves. Therefore, adding a new kind of constant pool entry requires changes in many classes, since higher level clients are not shielded from changes in the underlying constant pool representation.

4) When writing, pool entries are too eagerly turned into indices; that sometimes creates issue, where the Code class would like to know the contents of the original entry in order to update the code state accordingly (e.g. after an ldc instruction). This means that, currently, Code has to piggy back into the constant pool and lookup entries by index.

5) The lack of an API for reading/writing pool entries results in duplicate code; ModuleNameReader is a perfect example of that - that class being essentially a subset of ClassReader, where 90% of the duplication lies in the logic for handling and resolving pool entries.

6) The absence of a type describing pool constants makes also code for handling dynamic symbols harder - since static constants must be expressed as Object arguments. Augmenting the pool API might offer some relief in this area too.

7) More generally, class reading/writing code is too low-level and unnecessarily bit-oriented; this is mostly caused by the fact that javac's ByteBuffer abstraction does not exposes all the relevant helper functions which would allow clients to fully operate with it.

We should replace the existing logic with a cleaner architecture which features two symmetric abstractions, namely PoolWriter and PoolReader. PoolWriter takes a javac entity E and yields an index (the constant pool index at which the entry has been stored). PoolReader does the opposite, turning indices into javac entities of given kind.