Thanks! would try 2.25.0-SNAPSHOT for a while then.
Piotr P. Karwasz <piotr.karw...@gmail.com> 于2024年10月17日周四 14:24写道：
> 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
>
>
