JEP 330 class loader getResourceAsStream

[David Lloyd]

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.
On Fri, Aug 24, 2018 at 12:21 PM seth lytle <seth.lytle at gmail.com> wrote:
>
> JEP 330 (launch single-file source programs) uses a MemoryClassLoader. the
> compiled bytecode is stored in byte arrays in memory and is never written
> to file. currently, the bytecode is not exposed as resources and it would
> be advantageous to do so (enabling the use of eg ASM to modify the classes
> to implement continuations). this class loader has no resources other than
> the bytecode
>
> getResourceAsStream would be easy to implement. getResource would be
> significantly harder - a new url scheme and associated plumbing would be
> needed
>
> jonathon gibbons wrote on compiler-dev:
> > I would defer to ClassLoader experts as to whether it is reasonable
> > to provide getResourceAsStream but not getResource.
> >
> > It might be reasonable the jdk.compiler module to provide a
> URLStreamHandlerProvider for these URLs;
> > that would require some consideration.
>
>
>
> is it reasonable to expose a resource via getResourceAsStream that's not
> available via getResource ?
>
>
> the javadocs for getResource state "returns ... null if ... a URL could not
> be constructed to locate the resource". the javadocs for
> getResourceAsStream do not include such verbage, which appears to be
> precedent for such an arrangement



-- 
- DML