show how http URI origins don't work

[elharo]

java.nio.file.FileSystemNotFoundException: Provider "https" not installed at java.nio.file.Paths.get(Paths.java:147) at org.apache.commons.io.build.AbstractOrigin$URIOrigin.getPath(AbstractOrigin.java:402) at org.apache.commons.io.build.AbstractOrigin.getInputStream(AbstractOrigin.java:540) at org.apache.commons.io.build.URIOriginTest.testReadFromURL(URIOriginTest.java:47) at java.lang.reflect.Method.invoke(Method.java:498) at java.util.ArrayList.forEach(ArrayList.java:1257) at java.util.ArrayList.forEach(ArrayList.java:1257)

[garydgregory]

By default, there is no "ftp", "ldap", and so on, either ;-) The stock Java platform is extensible of course, using the file java.nio.file.spi.FileSystemProvider in the resource directory META-INF/services.

[elharo]

That is true, but that is an implementation detail. There's nothing in this class or API that indicates it should depend on which file system providers are installed. And this is about URIs, not file systems. I would be equally surprised if CharSequenceOrigin depended on file system providers.

URIOrigin should be able to provide at l;east streams and readers for any URL the JDK can handle.

Overall though as I explore this, I'm coming to the conclusion that Origin is attempting to provide an abstraction for something that doesn't exist. That is, there is no true common type for files, byte arrays, strings, URLs, etc. Hence all the UnsupportedOperationExceptions and surprising failures like this one.

[garydgregory]

I suppose it's semi-surprising that Java versions 11 and up don't support HTTP since they do provide an HTTP client. At least a read-only file system should be "simple" without getting into the whole WebDAV thing.

[elharo]

That's not quite accurate. Java versions 1 and up do support HTTP. They just don't support it as a file system since it really isn't a file system. Neither are byte arrays or char sequences, of course.

[ecki]

Not sure how useful this Origin abstraction is, but why would URIOrigin.getInputStresm not delegate to URI.getInputStresm?

[garydgregory]

@elharo If you rebase on git master, this should now work due to https://github.com/apache/commons-io/pull/630

[garydgregory]

Closing, this works now.

See org.apache.commons.io.build.URIOriginTest.testGetInputStream(String):

    @ParameterizedTest
    @ValueSource(strings = {
            "http://example.com",
            "https://example.com"
    })
    void testGetInputStream(final String uri) throws Exception {
        final AbstractOrigin.URIOrigin origin = new AbstractOrigin.URIOrigin(new URI(uri));
        try (final InputStream in = origin.getInputStream()) {
            assertNotEquals(-1, in.read());
        }
    }