commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ralph Goers <>
Subject Re: svn commit: r805384 - /commons/proper/vfs/trunk/core/src/main/java/org/apache/commons/vfs/
Date Wed, 19 Aug 2009 06:47:49 GMT

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


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

View raw message