commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 23041] - [collections][PATCH] OutOfMemoryError test case for MapUtils.verbosePrint.
Date Wed, 10 Sep 2003 16:56:03 GMT
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23041>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23041

[collections][PATCH] OutOfMemoryError test case for MapUtils.verbosePrint.





------- Additional Comments From apacheBugzilla@AMammenT.cotse.net  2003-09-10 16:56 -------
As the result of a previous submission of patches (Bug 20740) I already had 
planned some work to prevent this kind of recursion.  I attach a patch which 
actually does multiple things....

1) Modifies test cases to make duplicate any tests available for debugPrint 
apply to verbosePrint and vice-versa (there were a few tests present for one 
and not the other, and it seemed easy to do).  

2) Updates verbosePrintInternal to also pass an internal stack of previously 
visited maps.  If a previously visited map is seen again, the text "(ancestor
[i] Map) is printed out as the value of the Map, where i refers to level of 
ancestor - the parent of the current Map is 0, the parent's parent 1, and so 
on.... 

3) Modified the test in the previously attached patch (<a 
href="showattachment.cgi?attach_id=8120">attachment=8120</a>); effectively 
replacing it with an alternate version that tests for the behaviour mentioned 
in #2 above.  If the test is executed on unmodified code, an OutOfMemory error 
should be generated as previously.  Also added an equivalent test for 
verbosePrint.  

Area of Concern 1 - the mechanism used for preventing infinitely recursive 
printing makes sense to me.  However, the exact notation for the text to print 
out when an ancestor map is included within the current map was something that 
I made up.  Anyone have better suggestions?  I just tried to go with something 
like the "(this Map)" text used for identifying the current map when one is 
included within itself.

Area of Concern 2 - The code recursively passes a stack of previously 
navigated maps along with the recursive call to print child maps.  Each 
element of the child's values is checked for existence in the stack in order 
to determine if the notation listed above should be used.  However, the check 
is done with Stack.contains().  Is this guaranteed to work?  I 
assume .contains calls .equals on members of the stack to determine if any 
specific element is already present.  I'm not sure what the guarantees are 
when you call .equals on a self-referencing Map.  It worked for the testcase 
with a TreeMap on the IBM JDK 1.3, but will it work in general?

Mime
View raw message