MethodHandles.Lookup.defineResource?

[Alan Bateman]

On 28/08/2018 07:55, Peter Levart wrote:
> :
>
> 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.
Right, and any class injected with Lookup.defineClass can be located 
with methods such as Class.forName or Lookup.findClass. There is no 
equivalent for resources, at least not without extending the ClassLoader 
API in ways that would work with existing implementations.

On the "Tip : Add resources dynamically to a ClassLoader" link that 
Stephen linked to. That is really a hack, or rather two hacks. The first 
hack is casting the system class loader to a URLClassLoader as that is 
making an assumption on the implementation type. The second is that it 
calls the protected addURL method from the wrong context, which will 
break once java.base is fully encapsulated. Aside from tool agents, it 
doesn't make sense to attempt to extend the class path dynamically link 
this. These articles/tips really need to create a URLClassLoader that 
locates the additional classes/resources and use core reflection to 
load/access them.

-Alan.