On Aug 18, 2009, at 11:07 PM, Mario Ivankovits wrote:
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.
I'm aware of that but I wouldn't be so bold as to change the minimum
JDK version without looking for input from other users first. Frankly,
my organization has switched to JDK 6 (which has some other nice
features), but I know there are a lot of users who haven't gone to that.
I would love to introduce generics and for each loops where appropriate.
However, we should be fairly close to a 2.0 release. I've gotten
checkstyle down to about 1,000 errors and can easily get it down to
about 500. Unfortunately, the BZip classes have lots of constants in
them that cause quite a few checkstyle errors and I really don't want
to mess with it. I believe there are a few other issues outstanding
that should be fixed but I'm pretty happy with the way VFS is working
for me. If we just change the minimum version but don't make many code
changes to take advantage of it until 2.1 that would be OK with me.
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.
I was thinking along the same lines.
Ralph
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
