Proposal: #BootstrapClassLoaderSearchInJVMTI

[Tim Ellison]

mark.reinhold at oracle.com wrote on 30/06/2016 00:31:00:
> 2016/6/29 3:45:53 -0700, tim_ellison at uk.ibm.com:
> > mark.reinhold at oracle.com (Mark Reinhold) wrote on 28/06/2016 22:22:15:
> >> Issue summary
> >> -------------
> >> 
> >>  #BootstrapClassLoaderSearchInJVMTI --- The JVM TI API [1] defines a
> >>  function, `AddToBootstrapClassLoaderSearch` [2], by which an
> >>  instrumentation agent can append a file-system path element to the
> >>  bootstrap class loader's class path.  ...
> >> 
> >> Proposal
> >> --------
> >> 
> >> Retain this method.  Do not deprecate it.
> > 
> > What would be the effect calling this function on a modular runtime 
when
> > passed a directory search path segment? a modular JAR? a regular JAR?
> 
> It will work just as it does today.
> 
> If the bootstrap class loader cannot locate a suitable class file within
> the run-time system then it will consult the path defined by calls to
> this function.  Each element of the path can be either a JAR file or an
> "exploded" directory tree corresponding to a package hierarchy.  Whether
> a JAR file is a modular JAR is of no import -- any module descriptor
> within it will be ignored.

Just to check I fully understand, this function will affect the search 
path
of the unnamed module associated with the bootstrap class loader, correct?

If that's so then I'm happy with the proposed solution.

Thanks,
Tim

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU