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 >
