Default values (EDEFAULT) for EAttributes that use EDataTypes with EType paramters (generics) is not generated

[claesrosell]

Hi.

I do not know if this is a bug or not. Hence, I started a discussion first.

"default value literal"'s on EAttribute:s which uses an EDateType with EType parameters (generics) does not seem to be fully supported.

To explain the problem I am using this simple meta model

<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="MyModel" nsURI="http://example.org/myModel.ecore" nsPrefix="org.example">
  <eClassifiers xsi:type="ecore:EDataType" name="EMyDataType" instanceClassName="org.example.types.MyDataType">
    <eTypeParameters name="T"/>
  </eClassifiers>
  <eClassifiers xsi:type="ecore:EClass" name="MyClass">
    <eStructuralFeatures xsi:type="ecore:EAttribute" name="MyAttribute" defaultValueLiteral="1">
      <eGenericType eClassifier="#//EMyDataType">
        <eTypeArguments eClassifier="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EFloatObject"/>
      </eGenericType>
    </eStructuralFeatures>
  </eClassifiers>
</ecore:EPackage>

A simple EClass called MyClass with one single EAttribute myAttribute which uses the EDataType EMyDataType which in turn has a type parameter. The EAttribute is given the default value literal "1"

The generated code for MyClassImpl will miss a MY_ATTRIBUTE_EDEFAULT declaration and eIsSet() and eUnset() methods of MyClassImpl switch/case statement for the EAttribute will be generated to handle "null" as the default value.

@Override
public void eUnset(int featureID) {
    switch (featureID) {
        case MyModelPackage.MY_CLASS__MY_ATTRIBUTE:
            setMyAttribute((MyDataType<Float>)null);
            return;
    }
    super.eUnset(featureID);
}

So if something like this is done:

MyClass myObject = MyModelFactory.eINSTANCE.createMyClass();
Object myValue= myObject.getMyAttribute(); 

myValue will have the value null

However, the initializePackageContents method of the generated MyModelPackageImpl class will be generated to support default value of the EAttribute.

initEAttribute(getMyClass_MyAttribute(), g1, "MyAttribute", "1", 0, 1, MyClass.class, !IS_TRANSIENT, !IS_VOLATILE, IS_CHANGEABLE, !IS_UNSETTABLE, !IS_ID, IS_UNIQUE, !IS_DERIVED, IS_ORDERED);

So if I call:

Object defaultValue = MyModelPackage.Literals.MY_CLASS__MY_ATTRIBUTE.getDefaultValue();

... the default value will be an instance of MyDataType ( created from the string "1" via MyModelFactoryImpl.createEMyDataTypeFromString() )

I have looked into the jet templates and the genmodel and the .hasEDefault() method of GenFeatureImpl.java explicitly checks if there are type parameters defined and if so, it returns false:

  public boolean hasEDefault()
  {
    return 
      getEcoreFeature() instanceof EAttribute && 
        (getEffectiveComplianceLevel().getValue() < GenJDKLevel.JDK50 ||
           (getEcoreFeature().getEType() != null &&
               getEcoreFeature().getEType().getETypeParameters().isEmpty() && 
               getEcoreFeature().getEGenericType().getETypeParameter() == null &&
               getEcoreFeature().getEType().getInstanceTypeName() == getEcoreFeature().getEType().getInstanceClassName()));
  }

So my question really is: Is this expected behavior or is it a bug?

[merks]

Perhaps it's a corner case not explored in the previous 18 years. The method could test if getDefaultValueLiteral is not null as an additional || condition. E.g., maybe something like this has minimal chance of regression while covering your case:

[claesrosell]

I have been a user of EMF almost all that time and I found this yesterday. We are using CDO as well and the default values of a new object seem to work a bit differently with eDynamicGet() and the CDOStore. In our environment, the problem only happens after a call to .eUnset().
I found one other comment about this behavior. In 2015 (https://www.eclipse.org/forums/index.php?t=msg&th=633567&goto=1694614&#msg_1694614).

I will set up an EMF development environment and do some testing

[claesrosell]

I have tested to generate our meta-models with your suggested change and for them, it seems to work without any unwanted side effects. Should I create an issue and provide a PR?

[merks]

Yes please.