Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: Seems to me the HashMap --- Hashtable change could be made against HEAD. It's only NECESSARY for 1.1 compatibility but it poses no great problem for a 1.2 compatible version; it isn't as if this would impact some functionality deep in the core of the product. So after this is done, a NET_1_1_1 tag could be created and that could be the final of this branch. +1; same as Jeffrey suggested. On the other hand, if there are other 1.1 incompatibilities we may want to fix those too, and then this might get a little problematical. Hey, Jeffrey, do you know if there's an easy way to make Maven do a JDK 1.1 compile? Or would it be easier to just tinker with the generated ant script? +1 to fixing all 1.1 incompatibilities before branching. I skipped ahead in the thread and see Jeffrey already answered how to run compile for 1.1 with Maven. On the subject of the pluggable parser factory, I'm not sure I see the need, but it's easy enough to do it that way, so I will make the change. Am I If there really isn't a need, don't do it. I just thought users may need to be able to customize the method used to determine which parser is returned. I thought it would become an issue when you started writing code that created parsers using the static factory method. correct in assuming that in your plan there would be a default implementation, with other factories being selectable instead on the basis of a property? I figured an automatic detector would accept a parser factory as an argument in either a constructor or detection method. The default constructor or default no-argument method would use a default implementation (whatever you were writing for the static method). That users could provide their own factories for systems we haven't anticipated. Probably they'd just subclass the default implementation, override the factory method, provide their own detection code for the systems they care about that we don't handle, and delegate to the superclass method anything else. Alternatively, there may be situations where they want to implement something from scratch, in which case they would just implement the interface. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: This code was calling a method in ORO that returned a Collection, also not JDK1.1 compatible. Since the older ORO method that returned a Vector had been deprecated, I looked at what it was doing, which was simply splitting a string on a comma. This was an overkill use of ORO, easily replicated with a StringTokenizer. Oh yeah, it's way better to use StringTokenizer when you're splitting on just a constant string rather than an actual regular expression. However, if there's anything that doesn't work in 1.1 because of ORO, I can get off of my ass and finally do the multi-version compilation support we'd talked about on oro-dev. We wanted to use conditional compilation to simultaneously support J2ME, J2SE 1.2, and J2SE 1.4. J2ME support effectively makes it JDK 1.1 compatible, so we could also throw in a JDK 1.1 target. The changes are minor; the equivalent of a few ifdefs. But it keeps J2ME folks from having to make the changes themselves and will take care of any Commons Net users who complain about Net breaking on JDK 1.1 because of ORO. At any rate, if the ORO dependency is the only thing preventing 1.1 compatibility I can take care of that over the next week. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Seems to me the HashMap --- Hashtable change could be made against HEAD. It's only NECESSARY for 1.1 compatibility but it poses no great problem for a 1.2 compatible version; it isn't as if this would impact some functionality deep in the core of the product. So after this is done, a NET_1_1_1 tag could be created and that could be the final of this branch. On the other hand, if there are other 1.1 incompatibilities we may want to fix those too, and then this might get a little problematical. Hey, Jeffrey, do you know if there's an easy way to make Maven do a JDK 1.1 compile? Or would it be easier to just tinker with the generated ant script? On the subject of the pluggable parser factory, I'm not sure I see the need, but it's easy enough to do it that way, so I will make the change. Am I correct in assuming that in your plan there would be a default implementation, with other factories being selectable instead on the basis of a property? On Wednesday 31 December 2003 10:42 pm, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], steve cohen writes: I am not completely CVS-literate and setting up the branches is beyond my current level of experience but probably would be good experience for me. In my response to Jeffrey's email, I asked about whether we wanted to replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch tag or leave the existing tag alone and attach a special branch tag with a different name to the NET_1_1_0 files. After we resolve that, if you want to do it, go ahead. I don't know if you can use the -F and -b options together with cvs tag, which is why I suggested the roundabout way of renaming the tag and creating a new one with the old name using -b. Subversion makes this easier. without requiring it to have far more knowledge of commons-net internals than I think is healthy. So I am developing an FTPFileEntryParserFactory and some convenience methods in FTPClient to enable Ant to be recoded decently. I followed the emails. Sounds great. I forgot to offer a comment. I was going to suggest making FTPFileEntryParserFactory either a class or an interface that has to be instantiated rather than a singleton. I think you were intending to make createFileEntryParser a static method. I suggest the use of an interface and a default factory class for the same reason we had to write SocketFactory and much later, in J2SE 1.4, Sun added its own javax.net.SocketFactory and javax.net.ServerSocketFactory. It allows generic code to be written that accepts pluggable parser factories should a user decide to implement his own factory. I'm thinking about the automatic detection code you alluded to, which could then be configurable/extensible through the insertion of parser factories. I can also make the HashMap--Hashtable change for the 1.1.1 branch. The JDK 1.1 incompatibility was DISCOVERED through failure of the unit test but the offending code is in the class being tested, not the test itself. I have Sure thing. Let's decide how to tag that branch. And it sounds like you have an itch for doing the nio stuff. It's been nagging me for a while, but I'm actually writing networking code these days based on java.nio, so I figure I should kill two birds with one stone and start rolling it into Commons Net as a proposal instead of keeping it in my private library. It's so much easier to dedicate volunteer committer hours when you're working on/using the stuff anyway. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote: Maven uses the following property: maven.compiler.target which defaults to 1.1 so what I last released generated 1.1 compatible class files. http://maven.apache.org/reference/plugins/java/properties.html Example: maven -Dmaven.compiler.target=1.2 clean jar Then I don't understand why I was able to build, since HashMap is not in 1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
I believe it just produces 1.1 compatible class files. Maven just passes the setting to the ant task, which passes it to javac. Since the HashMap class is is not present under 1.1 I guess we'd just get a ClassNotFoundException. I believe that should be all we need, we shouldn't need to *compile* with the javac from 1.1, we just need to use classes that are present with 1.1 and produce 1.1 compatible classes ( byte codes ). On Thu, 01 Jan 2004 10:57:24 -0600, steve cohen [EMAIL PROTECTED] said: On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote: Maven uses the following property: maven.compiler.target which defaults to 1.1 so what I last released generated 1.1 compatible class files. http://maven.apache.org/reference/plugins/java/properties.html Example: maven -Dmaven.compiler.target=1.2 clean jar Then I don't understand why I was able to build, since HashMap is not in 1.1. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
Yes, in order to verify that the code doesn't use any 1.2+ code I found that
you have to also use bootclasspath={path to jdk1.1.8 classes.zip}
There were a couple of other instances:
use of ArrayLists in VMSFTPEntryParser and in ExtendedNNTPOps.java
in the examples section.
I cleaned all of these up and committed them. In the case of the ArrayList in
VMSFTPEntryParser, it did not work to change the file container to a Vector.
This code was calling a method in ORO that returned a Collection, also not
JDK1.1 compatible. Since the older ORO method that returned a Vector had
been deprecated, I looked at what it was doing, which was simply splitting a
string on a comma. This was an overkill use of ORO, easily replicated with a
StringTokenizer.
Talk about a stroll down memory lane!
On Thursday 01 January 2004 02:18 pm, Jeffrey D. Brekke wrote:
I believe it just produces 1.1 compatible class files. Maven just
passes the setting to the ant task, which passes it to javac. Since
the HashMap class is is not present under 1.1 I guess we'd just get a
ClassNotFoundException.
I believe that should be all we need, we shouldn't need to *compile*
with the javac from 1.1, we just need to use classes that are present
with 1.1 and produce 1.1 compatible classes ( byte codes ).
On Thu, 01 Jan 2004 10:57:24 -0600, steve cohen
[EMAIL PROTECTED] said:
On Thursday 01 January 2004 09:06 am, Jeffrey D. Brekke wrote:
Maven uses the following property: maven.compiler.target which
defaults to 1.1 so what I last released generated 1.1 compatible
class files.
http://maven.apache.org/reference/plugins/java/properties.html
Example: maven -Dmaven.compiler.target=1.2 clean jar
Then I don't understand why I was able to build, since HashMap is
not in 1.1.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], Steve Cohen writes: But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. I misread your email (unfortunately an increasingly common experience given the volume of email I have to skim). I thought you said the unit test wasn't 1.1 compatible. Given that the 1.1 release was supposed to be 1.1 compatible, I'm in favor of replacing the HashMap with a Hashtable in a 1.1.1 release and doing a JDK 1.1 build to spot any other compatibility problems. After that, I say we branch the code. Without selectable I/O, we're forced to use inefficient kluges. The guts of the telnet implementation is an abomination, which I wouldn't be too concerned about except that it underpins the FTPClient command conversation. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. I don't think it's a non-starter. As long as we give advance warning about how the transition is being handled. Say we branch and commit to making bug fixes on the 1.1 tree for x number of month. Since ant is J2SE 1.2 dependent, we ought not move to 1.3 (what do we really gain from 1.3 anyway?). We can plan a series of 1.2 compatible releases for some pre-announced period of time all the while working on a J2SE 1.4 dependent 2.0 release on an experimental code branch. I know it makes maintenance more difficult, but the code is showing its age and not making an attempt to reimplement using java.nio is selling users short in the long run. I'm willing to take the initiative on the experimental or proposal branch. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). Available as a courtesy, but unsupported. We'll find out soon enough if anyone still needs JDK 1.1 compatibility if we migrate to 1.2 and announce no new features for 1.1.x releases and only bug fixes for those who request them. To summarize, I now believe the stepping stones should be J2SE 1.2 and then 1.4. J2SE 1.2 compatibility for releases 1.2.x - 1.9.x on the head branch and J2SE 1.4 for release 2.0 on an experimental branch. JDK 1.1 compatibility for 1.1.x releases on a 1.1 maintenance branch. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
This makes a lot of sense, Daniel, and as long as I stay unemployed, I will even have time to devote to the project :-) I am not completely CVS-literate and setting up the branches is beyond my current level of experience but probably would be good experience for me. I am working now on a system that should help our interface with Ant. There has been quite a bit of complaining on the Ant list about the ability to connect to non-unix servers. We'd previously developed the ability to parse other systems, but accessing them from an outside system like ant was still impossible. Ant could, of course, be recoded, but not, at this point, without requiring it to have far more knowledge of commons-net internals than I think is healthy. So I am developing an FTPFileEntryParserFactory and some convenience methods in FTPClient to enable Ant to be recoded decently. These changes will belong on the 1.2 branch. Since the strings accepted by this factory method will have been chosen so as to map to the output of the SYST command (with a backup facility for also accepting a fully-qualified classname of the parser class), this system could also be used to implement an auto-detect system. I personally feel that that is a bell-and-whistle that is less important than the ant interface, since a programmer will usually know what system he is connecting to, or can easily find out, but some have asked for it. I can also make the HashMap--Hashtable change for the 1.1.1 branch. The JDK 1.1 incompatibility was DISCOVERED through failure of the unit test but the offending code is in the class being tested, not the test itself. I have already checked in the fix to the test that does not expect the file list to be in an order that the parser cannot guarantee. And it sounds like you have an itch for doing the nio stuff. On Wednesday 31 December 2003 10:14 am, Daniel F. Savarese wrote: In message [EMAIL PROTECTED], Steve Cohen writes: But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. I misread your email (unfortunately an increasingly common experience given the volume of email I have to skim). I thought you said the unit test wasn't 1.1 compatible. Given that the 1.1 release was supposed to be 1.1 compatible, I'm in favor of replacing the HashMap with a Hashtable in a 1.1.1 release and doing a JDK 1.1 build to spot any other compatibility problems. After that, I say we branch the code. Without selectable I/O, we're forced to use inefficient kluges. The guts of the telnet implementation is an abomination, which I wouldn't be too concerned about except that it underpins the FTPClient command conversation. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. I don't think it's a non-starter. As long as we give advance warning about how the transition is being handled. Say we branch and commit to making bug fixes on the 1.1 tree for x number of month. Since ant is J2SE 1.2 dependent, we ought not move to 1.3 (what do we really gain from 1.3 anyway?). We can plan a series of 1.2 compatible releases for some pre-announced period of time all the while working on a J2SE 1.4 dependent 2.0 release on an experimental code branch. I know it makes maintenance more difficult, but the code is showing its age and not making an attempt to reimplement using java.nio is selling users short in the long run. I'm willing to take the initiative on the experimental or proposal branch. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). Available as a courtesy, but unsupported. We'll find out soon enough if anyone still needs JDK 1.1 compatibility if we migrate to 1.2 and announce no new features for 1.1.x releases and only bug fixes for those who request them. To summarize, I now believe the stepping stones should be J2SE 1.2 and then 1.4. J2SE 1.2 compatibility for releases 1.2.x - 1.9.x on the head branch and J2SE 1.4 for release 2.0 on an experimental branch. JDK 1.1 compatibility for 1.1.x releases on a 1.1 maintenance branch. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Next Steps - WAS Re: [net] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes: I am not completely CVS-literate and setting up the branches is beyond my current level of experience but probably would be good experience for me. In my response to Jeffrey's email, I asked about whether we wanted to replace the existing NET_1_1_0 tag with a new NET_1_1_0 branch tag or leave the existing tag alone and attach a special branch tag with a different name to the NET_1_1_0 files. After we resolve that, if you want to do it, go ahead. I don't know if you can use the -F and -b options together with cvs tag, which is why I suggested the roundabout way of renaming the tag and creating a new one with the old name using -b. Subversion makes this easier. without requiring it to have far more knowledge of commons-net internals than I think is healthy. So I am developing an FTPFileEntryParserFactory and some convenience methods in FTPClient to enable Ant to be recoded decently. I followed the emails. Sounds great. I forgot to offer a comment. I was going to suggest making FTPFileEntryParserFactory either a class or an interface that has to be instantiated rather than a singleton. I think you were intending to make createFileEntryParser a static method. I suggest the use of an interface and a default factory class for the same reason we had to write SocketFactory and much later, in J2SE 1.4, Sun added its own javax.net.SocketFactory and javax.net.ServerSocketFactory. It allows generic code to be written that accepts pluggable parser factories should a user decide to implement his own factory. I'm thinking about the automatic detection code you alluded to, which could then be configurable/extensible through the insertion of parser factories. I can also make the HashMap--Hashtable change for the 1.1.1 branch. The JDK 1.1 incompatibility was DISCOVERED through failure of the unit test but the offending code is in the class being tested, not the test itself. I have Sure thing. Let's decide how to tag that branch. And it sounds like you have an itch for doing the nio stuff. It's been nagging me for a while, but I'm actually writing networking code these days based on java.nio, so I figure I should kill two birds with one stone and start rolling it into Commons Net as a proposal instead of keeping it in my private library. It's so much easier to dedicate volunteer committer hours when you're working on/using the stuff anyway. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
On Mon, 29 Dec 2003 16:22:48 -0600, Steve Cohen [EMAIL PROTECTED] said: [SNIP] 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? This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. I happen to be building with 1.4.2 under linux, btw. -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. However, there might be room for discussion whether we want to leave 1.1 compatibility behind. Ant 1.6 now is compatible only with JDK 1.2 and above. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). On Tuesday 30 December 2003 09:01 am, Jeffrey D. Brekke wrote: On Mon, 29 Dec 2003 16:22:48 -0600, Steve Cohen [EMAIL PROTECTED] said: [SNIP] 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? This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. I happen to be building with 1.4.2 under linux, btw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [net] VMSFTPEntryParser bug?
Unfortunately I don't remember if it was discussed or not. I'm for leaving 1.1 behind, even if we need to make a compatible version at this point, but then moving on. Seems like 1.3 is doable. I wouldn't want to leave users out in the cold. I still want to provide a release that works with a given jvm version, but I don't think I want to freeze all development at that version so long. So maybe new development proceeds with newer version of the jvm or something? On Tue, 30 Dec 2003 14:11:31 -0600, Steve Cohen [EMAIL PROTECTED] said: But what about my point that what we have now is NOT 1.1 compatible? VMSFTPEntryParser broke that, although it could, if necessary, be reimplemented to use Hashtable instead of HashMap. However, there might be room for discussion whether we want to leave 1.1 compatibility behind. Ant 1.6 now is compatible only with JDK 1.2 and above. There was some discussion about mandating 1.3, but that met resistance from some. Let alone 1.4. That was a non-starter, as we've already heard from several users here on the other thread. Are there any users of Commons-Net who need 1.1 compatibility? (Remember NetComponents is still available). On Tuesday 30 December 2003 09:01 am, Jeffrey D. Brekke wrote: On Mon, 29 Dec 2003 16:22:48 -0600, Steve Cohen [EMAIL PROTECTED] said: [SNIP] 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? This has come up in regards to using some of java.nio in Commons/Net also. I say we leave the last release as 1.1 compatible and move on to using 1.4+ for new versions. I happen to be building with 1.4.2 under linux, btw. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- = Jeffrey D. Brekke [EMAIL PROTECTED] Wisconsin, USA [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NET] VMSFTPEntryParser bug?
In message [EMAIL PROTECTED], steve cohen writes : 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. +1 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? This is a good question. At first I was going to say it doesn't impact the tests; but if your tests are dependent on a specific JDK, then you never run them on other JDKs. I'm of the mind that we ought to agree on a plan to migrate to J2SE 1.4 features. Still, there's the issue of Ant, which has a dependency on commons net. I know they abandoned JDK 1.1 support in the latest release, but is their new baseline J2SE 1.2 or 1.4? Anyone who needs JDK 1.1 support can live with the 1.1 release and we can support it in a separate branch applying bug fixes if there is sufficient demand. Another alternative is to start an experimental branch intended to become Commons Net 2.0 and continue releasing 1.x releases that meet Ant's compatibility requirements. Commons Net 2.0 could be a fundamental redesign and reimplementation based on the new IO features present in J2SE 1.4. The guts of the code would change, but not all of the protocol logic built around it, so it's not like it would be a complete rewrite. A lot of the kluginess in Commons Net stems from the lack of java.nio at its genesis. At any rate, until we hash some of this out in more detail, my vote is to support whatever Ant requires for compatibility. If it's J2SE 1.2, then HashMaps are okay in the unit tests. daniel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NET] VMSFTPEntryParser bug?
On Monday 29 December 2003 04:27 pm, steve cohen wrote: 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 a 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[net] VMSFTPEntryParser bug?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[NET] VMSFTPEntryParser bug?
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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [NET] VMSFTPEntryParser bug?
On Monday 29 December 2003 04:27 pm, steve cohen wrote: 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 a 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
