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