JEP 330 class loader getResourceAsStream (original) (raw)

David Lloyd david.lloyd at redhat.com
Fri Aug 24 17:27:38 UTC 2018

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

--

More information about the core-libs-dev mailing list