MethodHandles.Lookup.defineResource? (original) (raw)

Alan Bateman Alan.Bateman at oracle.com
Tue Aug 28 07:17:18 UTC 2018

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.

More information about the core-libs-dev mailing list