speed of class loading via a modulepath

Alan Bateman Alan.Bateman at oracle.com
Mon Nov 19 08:53:00 UTC 2018

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.


More information about the core-libs-dev mailing list