speed of class loading via a modulepath

Richard Hillegas rhillegas at comcast.net
Mon Nov 19 14:42:53 UTC 2018

Thanks, Rémi and Alan.

On 11/19/18 12:53 AM, Alan Bateman wrote:
> On 18/11/2018 20:00, Richard Hillegas wrote:
>> I am updating Apache Derby documentation to reflect the recent 
>> modularization of the codeline. While doing this, I have stumbled 
>> across an old piece of advice from the Derby Tuning Guide:
>> "The structure of your classpath can affect Derby startup time and 
>> the time required to load a particular class.
>> The classpath is searched linearly, so locate Derby's libraries at 
>> the beginning of the classpath so that they are found first. If the 
>> classpath first points to a directory that contains multiple files, 
>> booting Derby can be very slow."
>> That may be an old, Java 1.2 concern, which no longer affects modern 
>> JVMs. I have a couple questions:
>> 1) Is this still good advice when booting a large application like 
>> Derby via a classpath?
>> 2) What about the modulepath? Can classes be faulted in faster by 
>> re-arranging the order of jar files on the modulepath?
> The position of the directory or module on the module path won't 
> impact class/resources loading as modules are accessed directly (as 
> Remi notes) so no linear scan/searching after startup. Ordering is of 
> course important when you end up with a multiple versions of the same 
> module on the path, in that case the first version of a module wins.
> One other thing to be aware of is that the initial scanning of the 
> module path can be slow when it contains lots of automatic modules or 
> modules that have been packaged with the jar tool from JDK 8 or older. 
> Explicit modules that are packaged with the JDK 9 (or newer) jar tool 
> are indexed at packaging time to avoid scanning the contents at startup.
> -Alan

More information about the core-libs-dev mailing list