There are API changes in Java 9+ related to internal classes we needed in previous versions. There's a bit of history behind that documented here: https://logging.apache.org/log4j/2.x/log4j-api/apidocs/org/apache/logging/log4j/util/StackLocator.html
On Thu, 21 May 2020 at 09:06, Christopher <ctubb...@apache.org> wrote: > > I'm curious: what is the basis for the multi-release builds in the > first place? Is the code actually different for the two versions or is > it just to address build-related issues? > > On Sun, May 17, 2020 at 4:02 PM Ralph Goers <ralph.go...@dslextreme.com> > wrote: > > > > I kind of doubt it. Logging runs up against this primarily because Oracle > > dropped support for sun.reflect.Reflection at the same time they added > > StackWalker. Most everything else had years to switch to a replacement. > > > > https://www.elastic.co/blog/elasticsearch-java-9-and-beyond > > <https://www.elastic.co/blog/elasticsearch-java-9-and-beyond> - Elastic > > only tests against the Java version you have chosen to compile with. They > > rely on their CI tools to run multiple builds to these the combinations. > > > > I have seen mentions of other components that are delivered as > > multi-release jars but as far as I can tell Log4j 2 was the first > > mainstream library to do it so many of the problems with it have been > > encountered by us. > > > > Ralph > > > > > > > > > On May 17, 2020, at 11:03 AM, Volkan Yazıcı <volkan.yaz...@gmail.com> > > > wrote: > > > > > > Maybe a naive question, but... Does anybody know how other Apache > > > projects deal with this? Do they also require multiple JDKs to be > > > present at compile time? Do they also employ `java9` directory work > > > arounds as in log4j? > > > > > > On Sat, Apr 11, 2020 at 6:39 PM Matt Sicker <boa...@gmail.com> wrote: > > >> > > >> I was playing around with the pom a little bit yesterday when I came > > >> across a relatively new maven-compiler-plugin configuration element > > >> called <multiReleaseOutput> which can be used to output the compiled > > >> classes relative to META-INF/versions/N rather than the root. This > > >> looks like it would likely remove the need to use > > >> maven-assembly-plugin as an intermediary step. > > >> > > >> I found an interesting approach linked in [1] as the multi-release > > >> parent strategy with source code at [2]. I attempted to refactor > > >> log4j-api to use this pattern, but I couldn't figure out how to make > > >> the same pattern work for test classes (which made it impossible to > > >> compile log4j-api/src/test/java9). > > >> > > >> I'm going to continue experimenting a bit with this, but has anyone > > >> tried out the more recent multi-version tooling support? We were early > > >> users of some things, so I'd imagine tooling has caught up by now. > > >> > > >> [1]: > > >> https://maven.apache.org/plugins/maven-compiler-plugin/multirelease.html > > >> [2]: https://github.com/meterware/multirelease-parent/blob/master/pom.xml > > >> > > >> -- > > >> Matt Sicker <boa...@gmail.com> > > > > > -- Matt Sicker <boa...@gmail.com>
