AW: Issue implementing FileSystemProvider.getScheme()

[Christian Schlichtherle]

I wonder if there is a way to make the file system provider configuration
mutable at run time. This would make it easier to register file system
providers for custom application formats.

In contrast, in TrueZIP you can use a TArchiveDetector to decorate the
initial setup detected by a ServiceLoader. The decorating TArchiveDetector
can filter the initial setup or amend it. This way it's very simple to
register a an archive file system driver for a custom application file
format. Here's an example: http://truezip.java.net/usecases/aff.html 

Best regards,
Christian

> -----Ursprüngliche Nachricht-----
> Von: nio-discuss-bounces at openjdk.java.net [mailto:nio-discuss-
> bounces at openjdk.java.net] Im Auftrag von Christian Schlichtherle
> Gesendet: Samstag, 28. Mai 2011 15:23
> An: nio-discuss at openjdk.java.net
> Betreff: Issue implementing FileSystemProvider.getScheme()
> 
> Hi Alan,
> 
> I have a troublesome issue with implementing a FileSystemProvider for
> TrueZIP:
> 
> The problem is that FileSystemProvider.getScheme() can only return a
> single
> scheme. However, TrueZIP supports plenty of schemes which are
> discovered at
> runtime. So I cannot add a FileSystemProvider implementation class name
> for
> each scheme in META-INF/services/java.nio.file.spi.FileSystemProvider
> at
> compile time.
> 
> The workaround I am using now is a dirty hack:
> 
> <de.schlichtherle.truezip.nio.fsp.TFileSystemProvider>
> public class TFileSystemProvider extends FileSystemProvider {
> 
>     private static final String[] SCHEMES = .; // auto discovery here
> 
>     private final String scheme;
> 
>     TFileSystemProvider(final int scheme) {
>         this.scheme = SCHEMES[scheme % SCHEMES.length];
>     }
> 
>     @Override
>     public String getScheme() {
>         return scheme;
>     }
> 
>     public static class SCHEME00 extends TFileSystemProvider {
>         public SCHEME00() { super(0); }
>     }
> 
>     public static class SCHEME01 extends TFileSystemProvider {
>         public SCHEME01() { super(1); }
>     }
> 
>     public static class SCHEME02 extends TFileSystemProvider {
>         public SCHEME02() { super(2); }
>     }
> 
>     // and so on...
> }
> </de.schlichtherle.truezip.nio.fsp.TFileSystemProvider>
> 
> Now my registration looks like this:
> 
> <java.nio.file.spi.FileSystemProvider>
> de.schlichtherle.truezip.nio.fsp.TFileSystemProvider.SCHEME00
> de.schlichtherle.truezip.nio.fsp.TFileSystemProvider.SCHEME01
> de.schlichtherle.truezip.nio.fsp.TFileSystemProvider.SCHEME02
> ...
> </java.nio.file.spi.FileSystemProvider>
> 
> This is a hack because I have to guess the number of available schemes
> at
> compile time. If I guess too less, not all will be available. If I
> guess too
> many, the FileSystemProvider list gets populated with redundant
> entries.
> 
> A resolution could be simple: You could add a FileSystemProviderCatalog
> interface which looks like this:
> 
> <FileSystemProviderCatalog>
> public interface FileSystemProviderCatalog extends
> Iterable<FileSystemProvider> {
> }
> </FileSystemProviderCatalog>
> 
> Now you could use ServiceLoader to load all implementations. Then I
> would
> implement this to iterate over all my loaded file system drivers and
> create
> a FileSystemProvider for them.
> 
> Ahww, that's a metafactory... ;-)
> 
> Regards,
> Christian