[
https://issues.apache.org/jira/browse/LOG4J2-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16897437#comment-16897437
]
Adam Gent commented on LOG4J2-2649:
-----------------------------------
I looked into trying to first just make log4j2 start up faster independent of
GraalVM.
The startup time using programmatic configuration is 492ms!!!!!
Compare this to logback and the startup time is 47.84ms.
The reason why log4j2 has such an abysmal startup time appears to be the
enormous amount of static initializers through the code in the. Some of these
static initializers indeed do reflection that is not allowed by GraalVM.
Also log4j2 will try to load resources on initialization regardless of
configuration (the system properties override). Resource loading is not allowed
in GraalVM without telling it about it.
Finally log4j2 for some reason beyond me chose to implement its own
ServiceLoader (instead of the builtin java.util.ServiceLoader) that requires
an annotation processor to generate since its format is binary (like that
really shaves off time given the above problems). I would not be surprised if
the developers did not know about the builtin ServiceLoader and can't really
blame them because I'm not even sure Ceki did (I was the one who implemented
the ServiceLoader pattern for Logback as it was shockingly missing).
The reason the ServiceLoader is preferred is that GraalVM respects it unlike
custom implementations (that is no need to register the /MET-INF/services with
Graal).
All in all I'm pleased that log4j is now fairly garbage free and uses disruptor
but for a lambda function or android like project log4j2 is a poor choice and
probably for a very long time.
Logback is painful as well to work with GraalVM:
https://github.com/oracle/graal/issues/807
At this point I'm really tired of others implementing my logging frameworks so
I must just implement my own slf4j bindings that use no reflection and no
resource loading.
> Is Log4j2 considered to support successful static compilation under GraalVM?
> -----------------------------------------------------------------------------
>
> Key: LOG4J2-2649
> URL: https://issues.apache.org/jira/browse/LOG4J2-2649
> Project: Log4j 2
> Issue Type: New Feature
> Reporter: YangGuanchao
> Priority: Blocker
> Original Estimate: 168h
> Remaining Estimate: 168h
>
> Oracle released GraalVM [https://github.com/oracle/graal] to support the
> static compilation of Java applications to Native Image, which can increase
> the startup speed of Java by at least 10 times. In the cloud native field,
> this basic technology is believed to be in the near future. Will be supported
> by more and more vendors, such as the Spring/Spring Boot community has
> supported or plans to support the feature of GraalVM, see this issue:
> [https://github.com/spring-projects/spring-framework/search?q=Graalvm&type=Issues]
> can support static compilation, so it is recommended that Log4j2 also need
> to support static compilation as soon as possible, and can be compiled
> correctly under GraalVM.
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
