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
