Hi Richard, ----- Mail original ----- > De: "Richard Hillegas" <rhille...@comcast.net> > À: "core-libs-dev" <core-libs-dev@openjdk.java.net> > Envoyé: Dimanche 18 Novembre 2018 21:00:14 > Objet: speed of class loading via a modulepath
> 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? yes. > > 2) What about the modulepath? Can classes be faulted in faster by > re-arranging the order of jar files on the modulepath? For the modulepath, a module own the packages it contains so the VM maintains a map that associate a package name to a modular jar, there is no linear lookup to find a class anymore. Now, if you use the modulepath, you may have regression at startup compared to using the classpath because by default the module graph is created and checked at startup before running the application. For faster startup, you can combined jlink (that created one archive from all jars), appcds (prepare an image of the classes in memory), jaotc (pre-JIT the bytecode) or use graal native image (again pre-JIT + one image but with reflection limitation and its own GC). > > Thanks, > -Rick cheers, Rémi
