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?
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?
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: 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?
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?
> On Thu, 01 Jan 2004 08:16:13 -0600, steve cohen <[EMAIL PROTECTED]> said: > 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. This sounds like a good idea. Make the 1.1 compatibility on HEAD, tag, and if need be branch from that tag point for 1.1 fixes. > 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? 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 > 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] -- = 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?
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?
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]
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]
