commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <>
Subject RE: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/
Date Wed, 19 Aug 2009 06:07:50 GMT


> > 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.

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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message