Context

Found while comparing ECoreNetto against the reference Java EMF implementation, scoped to reading
.ecore files. The Ecore metamodel includes a generics facility: EGenericType (with
eClassifier, eTypeParameter, eTypeArguments, eUpperBound, eLowerBound) and
ETypeParameter (with eBounds), plus the serialized features eGenericType (on ETypedElement),
eGenericSuperTypes (on EClass), eTypeParameters (on EClassifier and EOperation) and
eGenericExceptions (on EOperation). EMF's own Ecore.ecore uses these (e.g. EEList<E>,
getFeatureType(...) : EGenericType).

Problem

ECoreNetto does not model any of this: the strings eGenericType, eGenericSuperTypes,
eTypeParameters and eGenericExceptions do not occur anywhere in the ECoreNetto project.
The corresponding child elements fall through the DeserializeChildNode overrides unmatched and
are silently dropped — a model using bounded or parameterized types loses all of that type
information without any diagnostic.

Related concrete defect: EOperation.EExceptions is a public property,

public List<EClassifier> EExceptions { get; private set; }

but nothing ever populates it — EOperation has no SetProperties override and the eExceptions
attribute is never read. Any consumer of the property silently sees an empty list even when the
model declares exceptions.

Suggested direction

• Populate EOperation.EExceptions from the eExceptions attribute (space-separated classifier
  references, same pattern as EClass.eSuperTypes).
• Model EGenericType and ETypeParameter and deserialize the four eGeneric*/eTypeParameters
  containments, at minimum preserving the raw structure so no information is lost; deriving the
  erased eType/eSuperTypes view from generics (as EMF does) can be a second step.
• Until generics are modeled, consider recording a warning Diagnostic when one of these elements
  is skipped, so users know information was dropped.