JEP 330 and MemoryClassLoader.getResourceAsStream

[Jonathan Gibbons]

John,

The worker class that performs the source-file launcher work is
passed the name of the source file as an argument, but it is not
passed down to the source code or class file in any way.

I don't think it makes sense for the compiled code to try and replicate
the compilation.  If we accept Seth's use case, it makes more sense
to open up getResourceAsStream, and possibly getResource.
My hesitation about getResource is that to would always want to
have a URLStreamHandler available in jdk.compiler, just for this
somewhat obscure (but interesting) use case.

-- Jon


On 8/24/18 3:59 PM, John Rose wrote:
> 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 <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
>>> - 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/25062eb3/attachment.html>