Issue with BuiltinClassLoader.ucp field not being visible

Luke Hutchison luke.hutch at gmail.com
Tue Aug 10 07:34:49 UTC 2021


The issue is that the Instrumentation.appendToSystemClassLoaderSearch
method "does not change the value of java.class.path system property"
(stated in the JavaDoc):

https://docs.oracle.com/en/java/javase/16/docs/api/java.instrument/java/lang/instrument/Instrumentation.html#appendToSystemClassLoaderSearch(java.util.jar.JarFile)

but classpath entries that are added to the end of the system classloader
classpath in this way are also not recorded anywhere else that is readable
by user code.

Without a method for reading these manual additions to BaseClassLoader.ucp,
there is simply no way to determine what if any jars or directories have
been added to the classpath using this mechanism.

What I'm asking for is some public API mechanism to determine what
additional classpath elements have been added to the end of the system
classloader path via the Instrumentation.appendToSystemClassLoaderSearch
method, so that classpath scanners can also work in the Java agent context,
if this method has been called to augment the classpath. Maybe that should
be part of the Instrumentation class, so that it is only accessible to Java
agent code that is able to get a reference to an Instrumentation object.




On Tue, Aug 10, 2021 at 1:16 AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 10/08/2021 07:58, Luke Hutchison wrote:
> > On Tue, Aug 10, 2021 at 12:51 AM Luke Hutchison <luke.hutch at gmail.com>
> > wrote:
> >
> >> Could a getURLClassPath() method please be added to BuiltInClassLoader?
> >>
> > For security reasons, the getURLClassPath() method should return a copy
> of
> > ucp, not the reference to ucp, to prevent the caller from modifying the
> > system classpath.
> I think you need more context here. This a JDK internal class so
> shouldn't be used directly. It reads like the original message was
> looking for the value of java.class.path as a sequence of URLs, is that
> right?
>
> -Alan
>


More information about the core-libs-dev mailing list