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

[Adam Sotona]

On 26.07.2022 21:43, "Brian Goetz" <brian.goetz at oracle.com> wrote:



To be more specific about the actual classes:
Mapping accepts only fragments, because it must render as single line and for example in XML it renders as single element with attributes.

OK, so this unearths a previously unstated requirement: that we be able to turn certain maps into attributes, rather than embedded elements, when converting to XML.  Does this requirement correspond to anything in other formats?  Do we gain anything by dropping this, and formatting always to elements, and/or using other heuristics to determine when we can get away with this format optimization?

In general, I'd like to unearth more of this sort of requirements.  Looking at the current hierarchy, I can't help but feel we've not yet "hit bottom"; it doesn't feel factored into separate concerns yet.  But I'm optimistic we can get there.

Here's a naive decomposition, which looks a lot like the JSON spec if you squint:

    Value = SimpleValue(ConstantDesc) | ListValue(List<Value>) | MapValue(Map<String, Value>)

Association with Java Maps and Lists is a mistake here. Every value must be named because every XML element or attribute must have a name and there is not a difference between rendering block list and block map in XML.
Mapping is a collection of named entries, where the keys are rendered in all formats.
List is a collection of named entries, where the keys are rendered in XML only.

We can make it more “square” and intuitive to Java developers as you propose, if we drop XML format.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220727/9eaf3a2c/attachment.htm>