This is now being tracked in JDK-8210009.
https://bugs.openjdk.java.net/browse/JDK-8210009
-- Jon
On 8/27/18 10:24 AM, seth lytle wrote:
david lloyd wrote:
AFAIK any code would expect that resources available as streams would generally
also be available as URLs
starting with java 9, the javadocs for getResource (but not for
getResourceAsStream) specifically allow returning null if "a URL could not
be constructed to locate the resource"
so even if code has some reason to prefer URLs for bytecode, it should know
to check AsStream as well
@david - i believe jon will address your earlier question about the
downside of getResource, so i haven't responded
On Mon, Aug 27, 2018 at 10:47 AM, David Lloyd <david.ll...@redhat.com>
wrote:
On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman <alan.bate...@oracle.com>
wrote:
On 24/08/2018 18:27, David Lloyd wrote:
Why not go ahead and implement getResource as well? It's not *that*
big of a deal to add a URL handler, and it would be a fairly trivial
one.
Right, it wouldn't be too hard but it would require a bit of plumbing to
have it backed by the Memory* classes in the source file launcher. That
said, a newbie starting out with "java HelloWorld.java" is unlikely to
be writing code that needs the class bytes so it's more likely the more
advanced cases where the code is using a library that needs the bytes.
AFAIK any code would expect that resources available as streams would
generally also be available as URLs. I'm not sure that distinguishing
between basic and advanced code really clarifies anything in terms of
the question.
--
- DML
