small changes, long build time

Ioi Lam ioi.lam at
Sat Apr 30 08:52:22 UTC 2016

> On Apr 30, 2016, at 3:53 PM, Alan Bateman <Alan.Bateman at> 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


> 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

More information about the build-dev mailing list