Please use the Apache issue tracking system for new NetBeans issues ( !!
Bug 98344 - Methods with multiplicity params with different Collection Types produces uncompliable code
Methods with multiplicity params with different Collection Types produces unc...
Product: uml
Classification: Unclassified
Component: Properties
All All
: P1 (vote)
Assigned To: Craig Conover
Depends on: 101255
  Show dependency treegraph
Reported: 2007-03-20 14:47 UTC by Sergey Petrov
Modified: 2007-05-11 14:58 UTC (History)
0 users

See Also:
Issue Type: DEFECT


Note You need to log in before you can comment on or make changes to this bug.
Description Sergey Petrov 2007-03-20 14:47:19 UTC
reproducible with 070319

1. create java peoject
2. add class
3. add Set<String> smth; attribute to the class
4. re the project to some uml project
5. generate code for uml project
new code has ArrayList<String> smth; attribute.
i.e. code/project logic is corrupted, in complex project it's hard to use
back-up to restore all such replacements.

in my opinion it wasn't good idea to fix rfe for Collection to arrays
tranformations without fixing rfe which request separate property for each
attribute to handle multiplicity to collections transformation.
Comment 1 Andrew Korostelev 2007-03-22 11:53:55 UTC
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) {

Comment 2 Craig Conover 2007-04-09 23:48:27 UTC
Requires enhancement issue 78473 to be integrated.
Comment 3 Craig Conover 2007-04-19 10:24:33 UTC
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

Comment 4 Sergey Petrov 2007-04-19 11:15:54 UTC
"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..
Comment 5 Craig Conover 2007-04-19 20:44:40 UTC
Yes, I meant Vector<Object> not Vector<String>. Copy/paste error.
The problem is with issue 101737.
Comment 6 Craig Conover 2007-04-19 21:05:32 UTC
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

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.

Comment 7 Craig Conover 2007-04-20 01:43:16 UTC
Trey provided the remaining efforts of the fix for issue 101255 and I backported
it to 5.5. This finishes fixing this issue.
Comment 8 Andrew Korostelev 2007-04-28 11:17:35 UTC
verified in all-nbms-griffin_fixes-070427-ml

By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo