JEP 330 and MemoryClassLoader.getResourceAsStream

[seth lytle]

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> 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
> - 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/20180823/18e46836/attachment.html>