eclipse-aascw / aas-core-codegen

85%

push

github

Compose the Java XML de-serialization (#690)

Java is the third backend to have its XML read side decomposed, after C#
(#686) and Go (#688), and it carried the repetition #686 described at four
levels rather than three.

Every property inlined its whole reading procedure into its own ``case``
block. Everything is now read through one composable shape, and
the pieces which do not vary are generated once:

    case "contentType": {
      final Reporting.Result<String> value =
        readTextAs_string(reader, isEmptyProperty);
      if (value.isError()) {
        valueError = value.getError();
      } else {
        theContentType = value.getResult();
      }
      break;
    }

The rationale and the design:

* A method reference to a ``static`` method captures nothing, so its
  ``invokedynamic`` call site is linked once and hands back
  the same instance afterwards; passing
  ``_DeserializeImplementation::readReference`` costs nothing.

  A capturing lambda is not free, and the old code had one in
  every ``try<X>FromElement`` and in every dispatcher, both closing over the
  enclosing ``reader``: an allocation on every single instance read. The
  read side now contains no lambdas at all -- every reader passed
  anywhere is a method reference to a static method -- so nothing can
  accidentally capture.

* Two shapes, and two only. ``ContentReader<T>`` reads the content of an
  element which has already been opened, ``ElementReader<T>`` reads a whole
  element. They are duals, and the wire format forces both, because it is
  asymmetric: an instance element is self-describing -- its local name *is*
  its type -- whereas a scalar element is not, its name being its position
  (the property's name, ``v`` in a list, ``v1``, ``v2``, ... in a tuple).

* One primitive, ``peekElementName``. It consumes nothing, and it is the
  single answer to "we are at an element, and this is its name". The framer
  ``readNamedElement`` checks that name against the one its cont... (continued)

229 of 231 new or added lines in 1 file covered. (99.13%)

33968 of 39820 relevant lines covered (85.3%)

2.56 hits per line