On Mon, 13 Mar 2023 13:47:31 GMT, Adam Sotona <asot...@openjdk.org> wrote:
>> `Classfile::buildModule` is a helper method simplifying the major use case - >> building valid module with minimal user effort and knowledge. It emits >> `ModulePackages` if there are any packages specified and not exported nor >> opened. That is the configuration which JVM expects and majority of users >> are not aware of. >> Other module-specific attributes can be added in the underlying handler, >> using `ClassBuilder::with`. >> >> A different building approach can be used in cases (which I would like to >> know more about) where even `ModulePackages` attribute needs to be >> "customised" or provided unconditionally. It is always possible to build >> module as a class using `Classfile::build` from scratch and provide all the >> attributes manually. > > Or another approach for the specific use cases might be to use > `Classfile::buildModule` with empty list of packages and then provide custom > `ModulePackagesAttribute` to the handler directly. > `Classfile::buildModule` is a helper method simplifying the major use case - > building valid module with minimal user effort and knowledge. It emits > `ModulePackages` if there are any packages specified and not exported nor > opened. That is the configuration which JVM expects and majority of users are > not aware of. ModulePackages is a performance optimization. When present, the value is the set of packages in the module. If not present, the module contents need to be scanned to discover the set of packages. I think it's just a bit too surprising for Classfile::buildModule to emit the ModulePackages attribute sometimes and not others. I think it would be better to change is so that calling it with ModuleAttribute will emit a Module attribute. The overloads that take a Module plus a set of packages can emit a Module + ModulePackage unconditionally. ------------- PR: https://git.openjdk.org/jdk/pull/11368
