Actually, it was addressed in Java 9 via StackWalker. So the mechanism to walk the stack changed completely between Java 8 and Java 9. I believe obtaining the Process id was also made easier in Java 9.
Ralph > On May 21, 2020, at 7:53 AM, Matt Sicker <boa...@gmail.com> wrote: > > 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> >
