Bug 78539

Description:
reproducible with 050606_20,

steps to reproduce:
1. create class diagram
2. add class 'a' to the diagram
3. check Collection Override property (it is ArrayList by default)
(Tools->Options, UML->Round Trip Engineering|Java)
4. add attribute with multiplicity
result:
array is used for source generation.


Evaluation:
The methods in roundtrip APIs that pertain to multiplicity don't appear to be
getting invoked at all.

Evaluation (Entry 2):
As per Trey, the changes probably need to be performed in ideintegration module
in the NBEventProcessor class. However, it appears that this is too late in the
process and the changes might need to be made in core module in
JavaAttributeChangeHandler in method multiplicityChange. I think this is where
the multiplicity is transformed into an array and the collection override should
be handled.

Major problem I see is that the collection override property is freeform, so how
are we to know exactly what to do with it? Perhaps this property needs to be a
prese list of available datatypes?

Evaluation (Entry 3):
After a lot of investigation and thought, if you wanted to use an ArrayList or
any sort of Collection instead of an Array (String[]), wouldn't you just specify
it as such: "ArrayList foo"? Or is this not following the UML standards?

Because the modeler is specifying an attr to be of type String, then they are
declaring the multiplicity. But if they want to use Collections, why not just
specify the collection datatype of choice for the attr type?

Again, I might just not understand UML spec very well.

Evaluation (Entry 4):
/
We shouldn't mix modeling and code generation even if we generate code after
each modeling step, if user wants a set of strings he will specify ... string[]
name in model to see the type and to have a set, but when user want code for his
model he may want to use collections in source (feature was introduced when
there were no generics, of cause with generics it may be more appropriate for
users to specify collection type with geneic in model too if we are supporting
such specification).
/
As for automatic recognition of collectins and automatic adding of
multiplicities we can't rean users' mind (I hope there will be MindReader class
in Java-10 :)) and ArrayList and ArrayList[] isn't the same, first have no
multiplicity and second have.. as an option we may ask user on each collection
we see in code what to do with collection and if user specify collection will
have srings we can update model with string[] instead of CollectionX, but I
think it's a wast of time, espesially there may be too many dialogs during RE of
big java project.

Evaluation (Entry 5):
fix failed, build 060423
main issue:
- collection override do not work with Use generics = No 
additional (with Use Generics=Yes):
- addition of private String A[*] leads to next code:
public class dds {
    private ArrayList<String> a;
    public dds() {
    }
    public ArrayList<String> getA() {
        return a;
    }
    public void setA(ArrayList val) { //BUG
        this.a = val;
    }
}
may be one more CR shopuld be filed:
- after addition of import java.lang.ArrayList with ALT+SHIFT+I generic is
removed from getter.
additional:
- add second 'private Object B[*]', next accessors are generated:
    public ArrayList<ArrayList<Object>> getB() {//BUG
        return B;
    }

    public void setB(ArrayList val) {BUG
        this.B = val;
    }
- in both cases model should use the same syntax as attribute i.e. String[] or
Object[], it uses ArrayList type in accessors.


Comments (Entry 1):

It might be necessary to make the Collection Override a drop down list of fixed
Collection subtype classes. Here is the current list that Java API knows about:

AbstractCollection, AbstractList, AbstractQueue, AbstractSequentialList,
AbstractSet, ArrayBlockingQueue,  ArrayList, AttributeList,
BeanContextServicesSupport, BeanContextSupport, ConcurrentLinkedQueue,
CopyOnWriteArrayList, CopyOnWriteArraySet, DelayQueue, EnumSet, HashSet,
JobStateReasons, LinkedBlockingQueue, LinkedHashSet, LinkedList,
PriorityBlockingQueue, PriorityQueue, RoleList, RoleUnresolvedList, Stack,
SynchronousQueue, TreeSet, Vector

Comments (Entry 2):

I was able to override array types with a Collection type (ArrayList), but this
negates the Multiplicity setting in the UML world. This maybe better than no
Collection Override setting at all, but it is not the right way.

Ultimately, we want the UML module to recognize a type as a Collection type and
set/preserve Multiplicity setting for the Attrribute as appropriate.

This still remains a challenge and needs to be resolved.


Comments (Entry 3):
About why not use collection instead of string with muliplicity, I have rfe on
java5 generics support addition to the feature, the issue may arise on forums
etc when main issue will be fixed.
About automatic determination of multiplicity for collection classes, I thin it
may be handled in separate isse, this issue cover only forward round trip while
automatic recognision cover backward roundtrip and work on diagram without
sources at all.


Comments (Entry 4):

I have considered the first point (using generics) with this fix, but realize it
requires the addition of another flag or more thought as to whether to use
generics or not. 

As to the last point about fwd/bwd RT engineering, if I just fix it going
forward, I cause a regression: multiplicities are broken/removed when RT is in
affect. I don't think this issue should be addressed without addressing the
whole issue.


Comments (Entry 5):

The fix was very simple as it turns out. The Collection Override code that
populates this preference was commented out and then still needed some
adjustment to populate correctly.

So the end result is that the modeler can enter any thing they want in the
Collection Override property, so it is up to them to make sure it really is a
valid Collection type and that it is spelled correctly.

In the UML model, the modeler will enter something like this:
private String foot[10]

and the code that is generated will look like this (assuming ArrayList is the
Collection Override datatype specified):
private ArrayList foo = new ArrayList();

However, the UML model will then be adjusted by changing the multiplicity from
[5] to [0,*]. Since an ArrayList is dynamic and not bounded by an initial value,
this is correct even if the modeler wishes to specify a bounded multiplicy
setting like 1..5 or such. Perhaps this will lead to another CR to fix it so
that the multiplicity is not tampered with.


Comments (Entry 6):

Now working on adding in a "use generics" option flag that will generate the
proper generics code. Some of the code was already there, it just wasn't being
invoked. Multi-dimensional collection generics had to be implemented so that the
following would work:

These model attribute elements:
public String foo
public String foo[]
public String foo[][]
public String foo[][][]

should generate this code:
public String foo;
public ArrayList<String> foo;
public ArrayList<ArrayList<String>> foo;
public ArrayList<ArrayList<ArrayList<String>>> foo;


Comments (Entry 7):
It's all working as expected. The one drawback and potentially a CR bug
candidate is that if you Update Model from Source, and you have an attribute of
type ArrayList<String>, it will update the model to show the UML Attribute
element like this: public ArrayList foo, with no multiplicity settings. This is
another area altogether and probably should be address so that forward and
backward trips are consistent.


Comments (Entry 8):
Still trying to build locally to ensure it doesn't break anything before I
commit the mods. Should happen by noon today (4/20).


Comments (Entry 9):

Fixes have been delivered. I would suggest trying to break this in any way
possible. I did some thorough nested array like String[][][][] to ensure the
nested generic ArrayList was generated properly and that the multiplicity is
preserved.


Comments (Entry 10):
I was able to fix the problem where the seter/getter doesn't get the right
generic/collection type when the attriute is created/modified in the model. But
I am still working on what should be done if the attribute is created as an
array type in the source... what should the model do? Should it create the
multiplicity attr and then turnaround and change the source code to be a
generic/collection type or leave the source code as is?


Comments (Entry 11):
I think the best way to do only what user do, i.e. model should show attribute
of type entred by user without multiplicity at least for cases like
ArrayList<String>
in case ArrayList<String>[] the is a multiplicity of cause
in case ArrayList<ArrayList<String>> I do not know too.. may be the same as in
first case.
What about non generic option?


Comments (Entry 12):
After considerable debugging efforts to find the correct interception point, I
believe I have found it and the appropriate way to handle it. Now it is a matter
of addressing all the possible permutations of the states of the following
conditions:

Model attr type
Model attr multiplicity
Source attr type
Attr added in source or model
Attr type changed in source or model
Soure attr's type is Collection type (when updating model)
Collection Override is active
Use Generics for Collections is active
and so on...