eclipse-aascw / aas-core-codegen / 34982437814

85%

push

github

Compose the Java XML serialization (#691) (#691)

Write-side dual of #690, as #687 was of #686 in C# and #689 of #688 in Go.

``visit{Cls}`` was a verbatim copy of ``serializeElement``: 38 methods of
18 lines each spelling out the start tag, the namespace, the content and
the end tag, around a call which already did exactly that. Six
near-identical emitters -- one per property kind -- produced the very same
``serializeElement`` call, differing only in the content serializer. And
everything was an *instance* method, because of one mutable ``topLevel``
flag.

That flag is what cost the most. It made ``this::writeStringifiedContent``,
``this::visit`` and ``(value, w) -> this.xToSequence(value, w)`` capturing,
and ``serializeItems(...)`` and ``asNamedElementSerializer(...)`` returned
capturing lambdas on top of them, so writing one instance allocated
a small pile of closures. It is replaced by a ``final boolean
withNamespace`` pinned in the constructor of two immutable visitors,
``ROOT`` and ``NESTED``: only the outermost element declares the
namespace, and an element written from ``writeClass`` is nested by
construction. Everything else is then ``static``, and a method reference
to a static method captures nothing.

The design is otherwise the read side's, mirrored:

* One shape, not two. ``ContentWriter<T>`` writes a value where the
  writer already is; ``writeElement`` frames it in a start and an end tag.
  There is deliberately no second delegate for a whole element, as there
  is on the reading side -- an element differs from a content only in what
  it writes, never in its shape. The reading needs the distinction because
  a content reader has to be told whether its element was self-closing,
  and a writer has nothing to be told. Use sites take
  ``ContentWriter<? super T>``, which is how Java spells the
  contravariance C# writes as ``in T``, so the single writer of an
  ``IClass`` serves wherever the writer of a more specific interface is
  expect... (continued)

133 of 139 new or added lines in 1 file covered. (95.68%)

33954 of 39795 relevant lines covered (85.32%)

2.56 hits per line