speed of class loading via a modulepath

[Richard Hillegas]

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
>