JEP 330 and MemoryClassLoader.getResourceAsStream

[Jonathan Gibbons]

This is now being tracked in JDK-8210009.

https://bugs.openjdk.java.net/browse/JDK-8210009

-- Jon


On 8/23/18 3:13 PM, seth lytle wrote:
> thanks Jon (and sorry for the duplicate msg)
>
> > I would defer to ClassLoader experts as to whether it is reasonable to 
> provide getResourceAsStream but not getResource
>
> is the core-libs-dev list the best place to ask if this is reasonable ?
>
> > provide a URLStreamHandlerProvider
>
> yes, that seems like a bigger job
>
>
>
> On Wed, Aug 22, 2018 at 3:41 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Hi Seth,
>
>     The provision of getResourceAsStream and getResource was
>     considered in the implementation of the Source File Launcher
>     feature ... and was dismissed at that time.
>
>     * There are no "normal" resources in the (internal)
>     MemoryClassLoader; there are only the class files generated from
>     the source file. This implies that the provision of these methods
>     in MCL is just for the benefit for folk wanting access to the
>     bytyes for a .class file. (I'm not that that's bad; I'm just
>     saying that is so.)
>
>     * Yes, we could reasonably easily provide getResourceAsStream, but
>     it seems weird to provide getResourceAsStream without also
>     providing an equivalent getResource, but URLs are not (currently)
>     supported for the content of the MemoryClassLoader.  Yes,
>     internally, some "fake" URLs are created to keep the API happy,
>     but these are not intended to be used by the end-user, and you'll
>     get an error if you try and open a stream from the URL.  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.
>
>     -- Jon
>
>
>
>
>     On 08/21/2018 11:07 PM, seth lytle wrote:
>>     i'm working on adding JEP 330 single-file source invocation
>>     support to kilim (an ASM-based continuations library for java for
>>     which i'm the primary maintainer). we're prepping to promote my
>>     fork to the main site and i'd like to be able to support java 11
>>     single-file source invocation as easily as classpath-based
>>     invocation, or at least confirm that the differences are intentional
>>
>>     - i need access to the bytecode to weave it at runtime
>>     - MemoryClassLoader doesn't provide getResourceAsStream
>>     - it does cache the bytecode, so providing this appears to be
>>     easy to implement
>>     - currently, i access it with a javaagent that mimics
>>     MemoryClassLoader.map
>>     - https://github.com/nqzero/kilim/#java-versions
>>     <https://github.com/nqzero/kilim/#java-versions>
>>     - getResource is also missing, and again, much of the plumbing
>>     appears to be in place
>>     - i haven't tried manually building the "memory:///" style urls
>>
>>     an example of my current invocation:
>>       cp=$(mvn -q dependency:build-classpath -Dmdep.outputFile=/dev/fd/1)
>>       $java11/bin/java -javaagent:${cp/:*} -cp $cp Xorshift.java
>>
>>     what i'd like to be able to do:
>>     $java11/bin/java -cp $cp Xorshift.java
>>
>>
>>     i saw a previous thread that mentioned getResource in passing but
>>     no discussion of whether it was considered (un)desirable. is this
>>     feature planned ? are there problems with introducing it ?
>>
>>
>>     thanks for the great addition to java - using JEP 330 feels fun
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20180827/5787056f/attachment-0001.html>