[
https://issues.apache.org/jira/browse/LOG4J2-2133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16276024#comment-16276024
]
Matt Sicker commented on LOG4J2-2133:
-------------------------------------
While JSON might be more common in the wild, I think adding standard
manifest.mf attributes for modules could have worked (which is how OSGi
declares its module metadata), though the JPMS developers might have felt that
it was too hacky and un-typesafe, though it just introduced a bunch of
compatibility issues instead. These types of incompatibilities between official
Java and Android "Java" are probably part of the reason why Oracle spent so
much time and money trying to sue Google over APIs.
If we deferred creation of the module-info.class file until runtime, how would
that even help? The module-info metadata are particularly useful for compile
time (JPMS is explicitly static normally unlike OSGi which is far more dynamic
about this).
Perhaps we could start by linking to upstream tickets about incorrect behavior
such as scanning for literally every file named "*.class" even when the file
name would normally be invalid (e.g., anything with dashes in the name would
normally be an invalid class name, so only scan for known files with dashes in
the name).
> Log4J 2 appears incompatible with Android platform due to inclusion of Java 9
> classes (class file version 53)
> -------------------------------------------------------------------------------------------------------------
>
> Key: LOG4J2-2133
> URL: https://issues.apache.org/jira/browse/LOG4J2-2133
> Project: Log4j 2
> Issue Type: Wish
> Components: API
> Affects Versions: 2.9.1, 2.10.0
> Reporter: Oleg Kalnichevski
> Attachments: Screenshot from 2017-11-28 09-41-37.png
>
>
> Log4J 2 appears incompatible with Android platform due to inclusion of Java 9
> classes (class file version 53). Please see screenshot attached.
> I fully admit that there might be a way to make Android ignore those files
> but it is still disheartening that Log4J 2 APIs have dependencies on things
> that go beyond providing a thin logging abstraction layer.
> Oleg
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
