Tim_Ellison at uk.ibm.com
Thu Jun 30 14:11:36 UTC 2016
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  defines a
> >> function, `AddToBootstrapClassLoaderSearch` , 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
> > 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
of the unnamed module associated with the bootstrap class loader, correct?
If that's so then I'm happy with the proposed solution.
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
More information about the jpms-spec-observers