On Sun, 14 Jan 2024 17:16:37 GMT, Claes Redestad <redes...@openjdk.org> wrote:
> Pre-existing issue here is that it seems we don't handle compressed resources > that can't fit in a single byte[], yet we take the overhead of storing > uncompressed/compressed size as longs (4+4 byte overhead per entry). I guess > we should either add code to handle huge entries or optimize the compressed > header to store int sizes. This limitation is so deep-rooted that it is difficult to resolve it for the time being. But I don't think this is causing any problems for the time being. There is no need to put an overly large resource in a jimage file, it will be better placed elsewhere. But even so, I think it's appropriate to store the size as 64 bits, which will make it easier to lift this restriction in the future. If you want the size of the metadata, I think it is more appropriate to compress the metadata. I tried using zstd to compress the metadata in [JApp](https://github.com/Glavo/japp) and got good results. We might be able to do this in jimage as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17405#issuecomment-1891175153
