generama test cases use ast parser to compare generated java files.
well, it's not generama which uses them, of course it's unit test
for xdoclet-2 plugins which happen to generate java code.
There is manually written java source, which serves as "correct"
code, and it is compared with generated one.
If I iterate over properties inside some method - test fails.
-------%<---------
setFoo("blurge");
setBar("bang");
-------%<---------
is not equal to:
-------%<---------
setBar("bang");
setFoo("blurge");
-------%<---------
I will raise dependency on xdoclet plugins and look where similar problem may arise.
I agree, ordering of collections should be consistent across JDKs, and across runs of QDox. IMHO source elements should be listed in the order they were declared in the original source.
I thought this was largely the case already, actually; in most cases, we maintain ordered lists of elements, append to the end while parsing the source, and make them available as arrays in the API.
Obviously, there must be cases where this is not true (or you wouldn't have raised this issue). Konstanstin, can you provided specific examples of calls that return Collections/Maps with inconsistent ordering? Thanks.