commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <>
Subject Re: [VFS] Generics fixes
Date Mon, 08 Nov 2010 10:37:55 GMT
Hi Sebb,

sebb wrote:

> On 8 November 2010 08:49, Jörg Schaible <> wrote:
>> sebb wrote:
>>> Most of the generics fixes have now been done.
>>> There are still a few raw Class references; most of these can be fixed
>>> if DefaultFileSystemConfigBuilder.getConfigClass() is changed to
>>> return a FileSystem [1]
>>> Can anyone else confirm that this is a sensible change?
>>> [1]
>> No. We use an implementation of FileSystemConfigBuilder that does also
>> not implement FileSystem to introduce more global configuration
>> parameters.
> So? None of the FileSystemConfigBuilder classes currently implement
> FileSystem.
>> What you can do is:
>> protected Class<? extends FileSystemConfigBuilder> getConfigClass();
> No, that won't work, because all the other getConfig() methods return
> subclasses of FileSystem.

I see.

> The only solution then would be to use Class<?> throughout.
> All I'm suggesting is changing the return class from
> DefaultFileSystemConfigBuilder.getConfigClass() to (say)
> FileSystem.class.
> The FileSystemConfigBuilder subclass getConfig() methods are not there
> because they implement the FileSystem interface, they implement the
> abstract method in FileSystemComfigBuilder.

I had a closer look at it now and it seems that Class<?> is the right 
solution. Basically the class type is used as a key to the options that 
apply for the current file system, but the stuff from 
DefaultFileSystemConfiguBuilder are available as options to all FS (as our 
implementation of FileSystemConfigBuilder does). It does not necessary have 
to be a FileSystem implementation, it's just a natural choice for a FS 

- Jörg

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

View raw message