> On Apr 30, 2016, at 3:53 PM, Alan Bateman <alan.bate...@oracle.com> wrote: > >> On 30/04/2016 08:32, David Holmes wrote: >> >> Just to add my concerns here, I was changing the launcher and building >> images and that caused the jmods to be rebuilt as well. I would not expect >> that so do we have missing dependency information in the build? > By "changing the launcher" then do you mean the native code, say in > jdk/src/java.base/share/native/? There are many modules with native launchers > and the launcher code is compiled for each one. If you instead mean > LauncherHelper or other java code then it's in java.base and so the classes > in that module need to be recompiled and of course everything depends on > java.base.
Maybe the build system can generate more fine grained dependencies? If only private or non exported classes/packages are updated, no other modules need to be rebuilt If only an exported package is updated, then only other modules that import this package need to be rebuilt Ioi > As regards the jmod files then they are the packaged modules. The linker > consumes these so they need to be built before we create the images. Also the > packaged modules are copied into the `jdk` image (by jlink) as it is needed > to create custom images. > > Anyway points to mention: > > 1. The jmod files are currently huge. This is mostly because of debug info. > Erik fixed this recently in jdk9/dev via JDK-8155632 but it may not have got > to all forests yet. > > 2. We have changes coming (should be in jdk9/dev by mid next week) that > avoids the need to generate the packaged modules in reverse topology order. > This is the change to the where the integrity hashes are recorded that I > mentioned in the first reply. This may help with the build times a bit > although generating the packaged modules is I/O bound so mileage may vary. > > -Alan
