zlib1g #23
zlib1g #23
Conversation
There was a problem hiding this comment.
Thanks for the detailed explanation of the motivation behind this PR- that was super helpful!
Everything looks good to me- I'm going to throw something in our backlog to actually merge the PR once it is approved by everyone, just to maintain team context
|
@martyspiewak Thanks for the quick review. I'm going to leave it in draft for a little while longer as I chase down a couple more leads to see if we can get GraalVM to change enough for us to not need it. I'll make sure to update as I learn more. |
|
@nebhale Sure! That makes sense- I didn't mean to to change it, sorry about that. |
|
@martyspiewak and @kvedurmu, I'd like this merged please. |
Previously, Java applications could not run on the tiny run image. With the advent of the GraalVM[1] Native Image[2] functionality, this is now a possibility. Native Images have few, but some library dependencies. Most of these libraries are already on the tiny run image, and two of the three that are not (libstdc++ and libgcc_s) can be statically compiled into the native image binary. However, there is a single library dependency on libz that cannot be compiled into the binary. This change adds the zlib1g package to the base images and the tiny run image. There are good reasons to minimize the collection of packages on base and especially tiny, but given that this library is quite commonly used and is the only barrier to Java native images on tiny I think it's a trade-off worth making. In addition, the list of libraries required by GraalVM native images has been constant for some time, and while it's impossible to predict the future, it is currently unlikely that any further libraries would need to be added to tiny. [1]: https://www.graalvm.org [2]: https://www.graalvm.org/docs/reference-manual/native-image/ Signed-off-by: Ben Hale <bhale@vmware.com>
|
Have we evaluated advantages / disadvantages of adding zlib1g in a launch layer vs. the stack? |
|
@sclevine Bringing it along compiled for each stack. Rebasing for |
Previously, Java applications could not run on the tiny run image. With the advent of the GraalVM Native Image functionality, this is now a possibility. Native Images have few, but some library dependencies. Most of these libraries are already on the tiny run image, and two of the three that are not (
libstdc++ andlibgcc_s) can be statically compiled into the native image binary. However, there is a single library dependency onlibzthat cannot be compiled into the binary.This change adds the
zlib1gpackage to the base images and the tiny run image. There are good reasons to minimize the collection of packages on base and especially tiny, but given that this library is quite commonly used and is the only barrier to Java native images on tiny I think it's a trade-off worth making. In addition, the list of libraries required by GraalVM native images has been constant for some time, and while it's impossible to predict the future, it is currently unlikely that any further libraries would need to be added to tiny.