Issue implementing FileSystemProvider.getScheme()

[Christian Schlichtherle]

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