I have an Entity with a legacy operation that is designed to return a List<Object>. Changing the expected return type is an option but a difficult one. I have tried the following approaches to set the type ( in MD 16.8 ):
Setting type to 'Object' with the type modifier of ''
Setting type to 'Object' with no type modifier
Setting type to 'Object' with type modifier of ''
In every case, my Daos (interface and base) will generate a method with return type of List<Object>. I have also tested having List<Object> as a operation parameter and I see the same result (List<Object>). I have no problem with Object with no multiplicity (not a generic in a List).
I have enableTemplating on, and I use multiplicity for the List. But the Object inside the list from the model is resulting in a List<Object> instead of a List<Object> being generated in the code. As mentioned above I used all the intuitive datatype settings that I could think of. This is a common occurence for me becuase when using hibernate's Query and SqlQuery classes, List<Object> is a very common return from the Query.list() method. I can avoid all this by doing unchecked casting later down in my implementation code, but the Object just seems more appropriate.
I tried what another poster suggested in a semi-related forum post: to create a phantom datatype to trick andromda into generating the right Type, but it did not work. I created a datatype in MD called 'Object' and assigned that to my return parameter's 'type'. I then changed multiplicity to '0..*' and tried regenerating, but instead of seeing a List<Object>, I again saw a List<Object>. It seems that andromda is actively stripping out the array type modifier when there is a multiplicity involved in a Type definition.
Related to metafacades under AssociationEndFacadeLogicImpl.handleGetGetterSetterTypeName and ModelElementFacadeLogicImpl.handleGetFullyQualifiedName.
java 1.6, maven 2.2, magicdraw 16.8, emf2.2 model