JEP 330 class loader getResourceAsStream

[Jonathan Gibbons]

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.lloyd at redhat.com>
> wrote:
>
>> On Mon, Aug 27, 2018 at 9:41 AM Alan Bateman <Alan.Bateman at 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
>>