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
