[NET] VMSFTPEntryParser bug?

[steve cohen <st...@javactivity.org>]

I am trying to build commons-net prior to making some changes and some other 
issues have come to light.

One of the tests is failing for me - 
VMSFTPEntryParserTest.testParseFileList().  

This test seems poorly implemented, since the class being tested builds its 
list of files using a HashMap to eliminate dupes, I presume, and then spits 
out the list by calling values() on the HashMap - which spits out the values 
in an order that is different from the one the test is expecting.  I was 
running this under java 1.3 on linux.  I switched to java 1.4 and it is also 
failing but on a different line.  I'm not sure what platform Jeff is on when 
he did the build, but I think I should rewrite this test in a way that 
doesn't assume any particular order since this seems to be JDK-implementation 
dependent.  The JavaDoc for HashMap specifies no order that should be 
expected for HashMap.values(), nor for HashMap.keySet() for that matter.  We 
could probably achieve a dependable order by using a TreeMap.keySet() 
instead.

However, this brings up the larger question, of what the target platform for 
commons-net is.  I dimly remember that it being java 1.1.  This is why I went 
through the annoying exercise of creating the FTPFileList and FTPFileIterator 
classes based on java-1.1-compatible containers like Vector.  If we are now 
using HashMaps, though, we will have violated this contract, if, in fact, 
such a contract exists.  Can someone clarify this question?


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org