show how http URI origins don't work #544
Conversation
|
By default, there is no |
|
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. |
|
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. |
|
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. |
|
Not sure how useful this Origin abstraction is, but why would URIOrigin.getInputStresm not delegate to URI.getInputStresm? |
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)