Hi Xeno,
On Thu, 17 Oct 2024 at 06:05, Xeno Amess <xenoam...@gmail.com> wrote:
> I ask, because a pretty large improvement in 2.25.0 will be graalvm
> native-image support, and I happen to be a graalvm native-image user
> recently...
> So I wanna hear about the possibility of getting a 2.25.0 or 2.25.0-rc1
> package from the official.
Yes, we are planning to release 2.25.0 soon, but you can use Log4j
Core 2.24.0 in a GraalVM application and even Log4j Core 2.17.1. See
our `log4j-samples-graalvm` example[1]. Let me explain how.
There are two kinds of problems you can encounter with GraalVM:
1. A library can use classes that GraalVM does not support, like
`LambdaMetaFactory`. Unbeknownst of the GraalVM implications I used
`LambdaMetaFactory` in `log4j-api` 2.19.0[2]. This was fixed in
`log4j-api` version 2.24.0[3]. As far as I know all the versions of
`log4j-api` up to `2.18.0` (included) and since `2.24.0` (included)
and all the versions of `log4j-core` work correctly with GraalVM.
2. If a library uses reflection, GraalVM needs Reachability
Metadata[4] to know which methods will be called. This data can be
provided:
i. By the community[5]: this is how Logback and other libraries
deal with GraalVM,
ii. By the application developer by providing your own reachability
metadata database: see the content of the
`log4j-samples-graalvm/src/reachability-metadata/minimal`[6] in our
samples repo. It is activated using the following Maven
configuration[7]:
<metadataRepository>
<enabled>true</enabled>
<localPath>${project.basedir}/src/reachability-metadata/minimal</localPath>
</metadataRepository>
iii. By the library developers themselves, by embedding the
configuration in the `META-INF/native-image` folder.
In version `2.25.0` we use method (iii), but you can easily extract
those JSON files from our snapshots[8] and put them in a
`META-INF/native-image/org.apache.logging.log4j/log4j-core` folder of
your application resources or you can create your own reachability
metadata database as in (ii).
If you are going to experiment with GraalVM and version 2.24.1, can
you check how big of a difference on your binary size does using the
full reachability-metadata from `2.25.0-SNAPSHOT` compared to the
minimal metadata I handcrafted in [6]. On our Hello Logging
application the difference is about 10 MiB[9], but I believe it should
be much smaller in a real life application.
Piotr
[1]
https://github.com/apache/logging-log4j-samples/tree/main/log4j-samples-graalvm
[2]
https://github.com/apache/logging-log4j2/commit/880acdfdb0b3c13c73c9ab3375924e238814f948
[3] https://github.com/apache/logging-log4j2/pull/2392
[4]
https://www.graalvm.org/jdk21/reference-manual/native-image/metadata/#specifying-metadata-with-json
[5] https://github.com/oracle/graalvm-reachability-metadata
[6]
https://github.com/apache/logging-log4j-samples/tree/main/log4j-samples-graalvm/src/reachability-metadata/minimal
[7]
https://github.com/apache/logging-log4j-samples/blob/8b71e0e5e1ad20471a6d8a9897e54da7faf7a0b2/log4j-samples-graalvm/pom.xml#L347-LL350
[8]
https://repository.apache.org/content/groups/snapshots/org/apache/logging/log4j/log4j-core/2.25.0-SNAPSHOT/
[9]
https://github.com/apache/logging-log4j-samples/tree/main/log4j-samples-graalvm#native-binary-size
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-user-unsubscr...@logging.apache.org
For additional commands, e-mail: log4j-user-h...@logging.apache.org
