On Wed, 20 Mar 2024 10:24:23 GMT, Severin Gehwolf <sgehw...@openjdk.org> wrote:
> 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 avoiding the plugin pipeline in creating a linkable image is simpler and more reliable design. I think it's worth understanding how big effort to support that. The reason why I proposed the alternative putting the diffs data as a side file under `lib` is an interim solution that would allow this work to continue while the API for extending jimage can be done as a follow up. > it seems almost too easy to change if it was a file outside the image. Only a few files in the `lib` directory such as libjvm.so or libjvm.dylib, src.zip and a few other files are intended for external use. All other files and directories under it must be treated are private implementation details and their names, format, and content are subject to change without notice. See JEP 220 for details. > 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). I agree that putting the diffs file in the jimage is a good direction. I am also ok with the interim solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2010349483
