ClassReader and BufWriter parity - Cleanup BufWriter!

[Chen Liang]

Hello Brian and CF list,
ClassFile API restricts user access to the raw bytes of a Class File. ClassReader is only there to support reading custom attributes, and we have just removed a few irrelevant methods in ClassReader in last few API changes in Java 23 to further restrict it. Great changes.

The same story goes for BufWriter. If you pay attention to how users can obtain it: yes, only in AttributeMapper! It is a parallel of ClassReader. Yet, it has way too many irrelevant methods, and can access too many things, such as WritableElement (why do you even need to write them in attributes!)

Basic plan for BufWriter is to remove non-attribute APIs from BufWriter, especially ones without ClassReader equivalents. Remember, we can always add them back if we need to!

Detailed actions (Removals to become impl details):
- [ ] `ConstantPoolBuilder.writeBootstrapMethods` ❌ BufWriter attribute only
- [ ] `LocalVariable.writeTo` ❌ BufWriter attribute only
- [ ] `LocalVariableType.writeTo` ❌ BufWriter attribute only
- [ ] `WritableElement` ❌ impl-internal interface like LabelContext
- [ ] `BufWriter`
  - [ ] `writeList` ❌ No `WritableElement`
  - [ ] `writeListIndices` ❔ consider exposing `BoundAttribute.readEntryList` in ClassReader for consistency (rename and ad check type), or hide both
  - [ ] `writeBytes(BufWriter other)` ❌ No multiple instances of BufWriter
  - [ ] `writeTo(BufWriter)` ❌ No multiple instances of BufWriter
  - [ ] `copyTo` ❌ No reading from BufWriter
- [ ] `ClassReader.compare` ❌ No reading from BufWriter

P.S. I previously proposed to remove LocalVariable(Type).writeTo alone; now this brainstorm allows us to truly understand the role of BufWriter and take throughout actions.

Regards,
Chen Liang

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