JEP 330 and MemoryClassLoader.getResourceAsStream

[John Rose]

What's the story for getting the pathname of the source file?
For example, shell shebang files sometimes use ${0} to do this.
If we point him to that, then he can reload and recompile the
sourcefile for himself.  IIRC, the story is "we don't do that', but
in that case this request could be viewed as another request
for that basic capability for shebang files.

I just grepped the shell shebang files in our source base and
found that 28 out of 187 of them refer to $0 somehow.  Seems
to me like a thing shebang files like to do.  If we don't support it,
maybe that's an RFE worth filing.  Of course, I may have forgotten
some good reason why we didn't do this, in which case sorry for
the noise.

— John

On Aug 22, 2018, at 12: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 <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/20180824/aa0188f1/attachment-0001.html>