Hi! > > IF you use the options in a way which allows you to know which kind > > of filesystem will be used - good - but then the builder is just > > another layer, but not awkward and brittle I think. > > No. They are awkward and brittle. WebDavFileSystemConfigBuilder > extends HttpFileSystemConfigBuilder. The getInstance method has to > return an HttpFileSystemConfigBuilder since you can't change the > return value of an overridden method.
Probably it is time to upgrade the minor jdk version for VFS-2.0. Starting with JDK 1.5 you can change the return type of an overridden method. It is called, covariant return types. http://www.java-tips.org/java-se-tips/java.lang/covariant-return-types.html Probably long overdue and an easy fix then. > > FileSystemOption then can be a concrete instance of a set of > > configurations for one specific filesystem, so you might have > > HttpFileSystemOption, SftpFileSystemOption etc. Each of them holding > > all possible filesystem options. > > I actually like this a lot more than the current implementation. > However, it wouldn't allow the get and set methods to be exposed at > compile time on the root FileSystemOptions class. I think that can be > worked around pretty easily. Yes, if we consistently name the new subclasses, we can instantiate these and reflect the getter/setter then. Ciao, Mario --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
