On Tue, 19 Mar 2024 18:05:31 GMT, Mandy Chung <mch...@openjdk.org> wrote:
> Thanks for the details. I feel the pain in extending jlink for this work as > the current jlink implementation is not easily understandable and has been > yearning for rewrite in my perspective (looking forward to Project Leyden's > condenser model). +1 > Really appreciate your effort for this. Sure. > IIUC, the main issue is regarding extending an jimage with additional entries. Yes, it's really extending the jimage with additional entries which isn't supported currently (outside the jlink + archive + plugin pipeline). > The other option is to add the diffs as a separate file in the JDK image > under `lib` instead of part of the jimage. Sure that would work. On the other hand, it's another additional artefact that downstream distributors need to account for. What's more, it seems almost too easy to change if it was a file outside the image. Thirdly, it would go against where the hermetic java work is going (one effort of this project is to try to include most of the conf/resource files outside the jimage inside the jimage, next to the classes that use them). > The per-module mapping metadata files can be generated as part of the normal > linking as the footprint is small. Sure. > Would that simplify it? I'm not sure. What we really want is some form of API to extend/patch an existing jimage preserving everything else. Perhaps I should look into that. Would that be worth doing? > I think the other issues may be solvable. It's not a question of being solvable. All the issues are solvable in some way. Question is how exactly we want to address them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2009217508
