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.ly...@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
