Classfile API proposal to integrate basic print functionality directly to ClassModel and MethodModel

[Brian Goetz]

Actual ClassPrinter is very monolithic by intention. It has been written for the very base purpose of seeing the content of ClassModel or individual MethodModel in human-readable form (as well as machine-readable).

Yes, agreed.

The implementation traverses the models and prints formatted output using custom internal templates. The monolithic printer code gives me a chance to reflect all changes in one single class and many changes are instantly handled during refactoring. Additional API/SPI layers would make it very complex, painful for maintenance and a nightmare for testing.

I’m not sure about this.  Yes, more knobs means more testing, but having simpler, well-defined layers also simplifies testing.

One thing that concerns me having “seen this movie before” is that highly complected APIs tend to have a high rate of enhancement requests, because the user can’t control things that they want to control.  So while a monolithic thing is easier to design the API for initially, over the long term, the cost of maintenance is higher.

 What you propose is to transform actual models (ClassModel, MethodModel…) into a kind of  “printable models” and then implement various transformers of these printable models to provide formatted output.

Yes, where those “printable models” are probably a standard data structure like Map, maybe involving a few custom record types along the way.

I’m not at all worried that this process will involve more rounds of copying data; since printing is the ultimate destination (probably on its way for a human to debug it), creating a few thousand extra objects is in the noise.

I think that another “printable” SPI layer is a bit of overkill, as anyone can already implement consumer of the actual Classfile API models to print whatever is needed.

Right, we could get away without a printing facility at all.  To me, the value-add here is that someone has gone through the work — once — to switch over all the kinds of elements that can appear in a XxxModel and turn them into something simpler.  The code to turn the “abstract model” into XML or JSON or whatever is probably trivial, but the code to turn the real models into abstract printable ones is a lot of kind-of-annoying case analysis, and I think this is where we will save the user time and frustration.

Let me propose an experiment: take the existing ClassPrinter implementation — still monolithic — and try refactoring to use internal “printable models”, where the keys in the output (e.g., “class name”) are derived from the keys in the printable model, rather than hard-coded format strings, and see how we like that?  That should be a small step, and if we like it, we can take another step.  If it turns out that is nastier to do that I am guessing, we can back off an think of another approach.


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