If this has already been reported, I aplogize in advance. However, I have discovered a severe problem with using edtftpj in a threaded environment, specifically related to the FTPClient.dirDetails() command.
It seems the Unix and Windows FTPFileParser implementations each use a static java.text.SimpleDateFormat instance to format dates received from the remote FTP server. This is bad in a threaded environment... SimpleDateFormat is not thread safe.
Concurrent calls to FTPClient.dirDetails() will produce exceptions that look like this:
java.lang.NumberFormatException: For input string: ""
at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Long.parseLong(Long.java:415)
at java.lang.Long.parseLong(Long.java:452)
at java.text.DigitList.getLong(DigitList.java:149)
at java.text.DecimalFormat.parse(DecimalFormat.java:1068)
at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:1705)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1156)
at java.text.DateFormat.parse(DateFormat.java:333)
at com.enterprisedt.net.ftp.WindowsFileParser.parse(WindowsFileParser.java:90)
at com.enterprisedt.net.ftp.FTPFileFactory.parse(FTPFileFactory.java:159)
at com.enterprisedt.net.ftp.FTPClient.dirDetails(FTPClient.java:1735)
I've seen other exceptions too, all related to invalid formats. This is because SimpleDateFormat's internal state is being changed.
The solution is to either make the "formatter" member variable of Unix/WindowsFileParser an instance variable (ie, non-static) or synchronize() around usages of it. I'll leave it to y'all to determine the best solution. In my local copy of the code, I have turned it into an instance variable simply to avoid lock contention.
edtftpj is by far the best and most efficient Java-based ftp API I've seen thus far. I hope this little issue can be fixed in the next release.
thanks!
eric ridge
