JEP 330 class loader getResourceAsStream

[seth lytle]

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