JEP 330 and MemoryClassLoader.getResourceAsStream

[seth lytle]

to add to what Jon said, recompiling doesn't necessarily provide the
correct info as it may have been manipulated by another agent or
classloader (there is a similar weakness in my current workaround)

getResourceAsStream (getRAS) is:
- robust: you know it's the same bytecode your parent CL used
- flexible: you can run woven and unwoven code concurrently
- chainable: downstream CLs will see your modifications


i haven't been able to think of anything that getResource adds, though some
people may use that instead

on the core-libs-dev list david lloyd wrote:
> 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.


@jon - would you like to reply to that or should i ?

my feeling is that we're better off without getResource (getR)
- the javadocs appear to allow differences between getR and getRAS
- getR adds complexity, startup cost and increases footprint
- we're not aware of a consumer of the getR api
- the only resource is bytecode, and that's naturally accessed as a stream
- many things are changing with java 11 so any bytecode-modifying library
is likely to need to make source code changes anyway

the only problem i see with not implementing getR is that there's no way to
convey to a hypothetical consumer of the API that the bytecode that they're
looking for is available via getRAS


On Sun, Aug 26, 2018 at 10:10 PM, seth lytle <seth.lytle at nqzero.com> wrote:

> to add to what Jon said, recompiling doesn't necessarily provide the
> correct info as it may have been manipulated by another agent or
> classloader (there is a similar weakness in my current workaround)
>
> getResourceAsStream (getRAS) is:
> - robust: you know it's the same bytecode your parent CL used
> - flexible: you can run woven and unwoven code concurrently
> - chainable: downstream CLs will see your modifications
>
>
> i haven't been able to think of anything that getResource adds, though
> some people may use that instead
>
> on the core-libs-dev list david lloyd wrote:
> > 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.
>
>
> @jon - would you like to reply to that or should i ?
>
> my feeling is that we're better off without getResource (getR)
> - the javadocs appear to allow differences between getR and getRAS
> - getR adds complexity, startup cost and increases footprint
> - we're not aware of a consumer of the getR api
> - the only resource is bytecode, and that's naturally accessed as a stream
> - many things are changing with java 11 so any bytecode-modifying library
> is likely to need to make source code changes anyway
>
> the only problem i see with not implementing getR is that there's no way
> to convey to a hypothetical consumer of the API that the bytecode that
> they're looking for is available via getRAS
>
>
>
>
>
>
>
>
> On Fri, Aug 24, 2018 at 8:47 PM, Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> 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> 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/20180826/83747d50/attachment-0001.html>