Bug 98344

Additional case that demonstrates not compilable code after RE+CG.
- create java project with class that contains the following methods:
    public void test(LinkedList<String> ccc){
    }
    public void test(ArrayList<String> ccc){
    }
    public void test(Vector<String> ccc){
    }
- RE it into UML project
you will get three similar methods:
    public void test(String ccc[0..*])
    public void test(String ccc[0..*])
    public void test(String ccc[0..*])
- Create code for this class.
It will comtain three same methods:
    public void test(ArrayList<String> ccc) {
    }

    public void test(ArrayList<String> ccc) {
    }

    public void test(ArrayList<String> ccc) {
    }

Requires enhancement issue 78473 to be integrated.

The RE duplicates all method params that are Collections with generics. For
example, the following scenario, the method

public void test(Vector<String> str);

gets RE'ed to model operation element 

public void test String[*,*] with Vector as the Collection Type for both ranges.
Key word here being "both" ranges. There should only be one range.

=====

Also, if a Collection doesn't have a generic type specified, like

public void test(Vector str);

then is gets RE'ed to 

public void test (Vector str) instead of String[*] str

"public void test(Vector str);" should be REed to
"public void test(Object[*] str)" 
or to "public void test(Vector str)" itself
but not to "public void test(String[*] str)"

In my opinion from Java developer view (not a designer view) I want to see
certain collections in model not arrays everywhere, so It's good to have this
options for re, but it's another issue..

Yes, I meant Vector<Object> not Vector<String>. Copy/paste error.
The problem is with issue 101737.

I changed the Subcomponent to "properties" because You don't need to RE to
reproduce and the failure is in the ability for the properties of the parameters
to supply the proper Collection override information, so Code Gen is not at
fault either. This has all been corrected by an implementation that allows
params/return types/attributes to specify a Collection Type for each range of a
multiplicity.

Issue 101737 addresses the duplication of ranges for RE'd Collection type
params. The interesting thing is that you can RE operations into duplicate
element names/signatures, but you can't create them from scratch in the model.
That makes sense, but there is a conflict of design here that should be sorted out.

Trey provided the remaining efforts of the fix for issue 101255 and I backported
it to 5.5. This finishes fixing this issue.

verified in all-nbms-griffin_fixes-070427-ml