On 08/28/2018 08:55 AM, Peter Levart wrote:
MethodHandles.Lookup.defineClass() allows a class to be pushed into an
existing ClassLoader & Module, but I'm unaware of an equivalent for
resources, and that seems like a gap, regardless of use case.
ClassLoader (the Java part of it at least, which is exposed as an API)
is a delegate of a VM. VM calls it when it needs the bytecode of a
particular class it wants to define lazily. The ClassLoader API is
such that at the end, the ClassLoader calls back into the VM to define
the class whose bytecode it obtained in its own way.
MethodHandles.Lookup.defineClass() in this respect "bypasses" this
searching mechanism and ClassLoader API entirely and "eagerly" defines
a class in the VM. ClassLoader API and its bytecode resource searching
logic is not involved here.
What you are proposing as "defineResource()" API is therefore not a
parallel of defineClass(). ClassLoader API is all about "searching"
for resources (bytecode and other kinds) while defineClass() has
nothing to do with "searching" and everything to do with VM internals.
Your proposed defineResource() would have nothing to do with VM and
everything to do with searching as it would just augment the search
logic of existing ClassLoader instance.
...thinking further... In any way, such defineResource() method would
have to be empty and declared in java.lang.ClassLoder. Why? Because its
purpose would be to augment the logic of ClassLoader.findResource(s)
method(s) and those methods are implemented by ClassLoader subclasses.
Each ClassLoader subclass implements its own particular strategy of
searching for resources. There's no way to "generically" inject
additional resources in each and every ClassLoader implementation. JDK
ClassLoader implementations could be made to "obey" the
defineResource(), but this would not be a universal "fix" and code
relying on defineResource() would only work in environments using JDK
ClassLoader implementations.
Regards, Peter
