[native-image] Override META-INF native image properties

[fhanik]

Feature request

Please include the following information:

Is your feature request related to a problem? Please describe.
A clear and concise description of what the problem is. E.g. I'm always frustrated when [...]

Describe the solution you'd like.
Some libraries include meta files for the native-image generator inside the JAR file at the META-INF/native-image/groupId/artifactId location.

The files often have to include reflection and resource data that encompasses all use cases.
When using a small portion of the library, it may be desirable to override this configuration with a provided one, a smaller one, to optimize the size of the binary.

Describe who do you think will benefit the most.
GraalVM users that compile the applications to native images will benefit since they will have a greater control over what is included in the image.

Describe alternatives you've considered.
Creating a repackaging step during a build cycle to repackage 3rd party jars is an option. This becomes hard to maintain.

[olpaw]

That would essentially boil down to support passing of a blacklist of META-INF/native-image/**/* locations. Should not be too hard to add. This would be a good candidate for a PR provided by the community.

[eginez]

Hey @fhanik, I am not sure this falls under the responsibility of the native-image build process. The optimization of the size of an image might require a pre-processing step which could be responsible of the above, in fact it seems like we the spring team is already doing something like that. We, the native-image team are trying, to keep the build-process focused on its core competency, namely building native executables.

[galderz]

I've found myself needing this today. Btw, not the first time asked, @Sanne already asked for this in #1884 last year.

[vjovanov]

I would be reluctant to introduce this feature as I believe, it would make the progress of the community slower. If there is a problem in the library, the right approach is to submit a PR to that library.

Also, as @eginez pointed out, this can be achieved via other means (e.g., preprocessing). I would like to understand why submitting a PR to a library is not possible? Also, what makes it hard to remove invalid properties from a JAR?

[maxandersen]

I would like to understand why submitting a PR to a library is not possible? Also, what makes it hard to remove invalid properties from a JAR?

1. libraries does not necessarily release with the speed you need
2. removing invalid properties means forking/modifiying which one can do (we know we will have to it already in quarkus as many libs don't apply these things properly)

note we will properly already need to do the #2 processing but still find it interesting we can explicitly turn off graalvm/native-image processing of bundled content to just reduce chance of surprises.

[galderz]

From the POV of Quarkus, an integrator, we try to make an environment as efficient as possible for our users. We do native image configuration that is more aggressive than what libraries are ready to offer to the general public. We are one of their use cases, and so it'd be unfair for us to impose such configuration on all the libraries' users. At the same time, it's unfair for integrators to be forced to apply configurations that are suited for a wide range of uses.

Preprocessing is certainly an option but it has many risks. E.g. what if we take someone's jar and due to filtering we forgot to add something new that gets added at a later stage? The other problem of preprocessing is that this is something that would likely be needed by other integrators out there, leading to a duplication of efforts.

[Sanne]

@vjovanov we've been sending PRs to upstream libraries often, but now since I don't have this switch I regret doing so: by the time such metadata is accepted, merged, a release is happened, and then other libraries of a more complex platform are ready to upgrade to such latest version, it's highly likely that some more tweaking is necessary.

For example, if we start working / experimenting with a new optimisation, a better way, or a new GraalVM version.

We're now at a point that the libraries which don't embed ay such metadata are easier to use on GraalVM; we highly need such a switch, or alternatively I'll start stripping such metadata out for the libraries I care about - which could imply removing such metadata, should we not have a better solution.

I would agree that basic compatibility rules do belong within each library, but without more flexibility this is severely problematc.

[Sanne]

P.S. I wrote about what we did in Hibernate ORM here:

• https://in.relation.to/2020/02/14/hibernate-orm-5-4-12/

In particular I should stress that I did move this metadata insto a separate Maven artifact, so to allow people to exclude it.

I also contribute to several other libraries (100+ !) but I won't be adding rules in META-INF in any library if we don't have a way to disable / override them; I had some POCs and it was too complex for all to agree on a static set of directives which would strike a good balance between "making things easier" and causing no problems in future maintenance.