Re: [Log4j] Potential simplification to java9 builds?

Yeah, the docs are out of date, but this was an ongoing problem from Java 6 to 7 to 8 to 9. On Thu, 21 May 2020 at 10:31, Ralph Goers wrote: > > 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 > o

Re: [Log4j] Potential simplification to java9 builds?

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 wrote: > > There are API changes in Java 9

Re: [Log4j] Potential simplification to java9 builds?

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 wrot

Re: [Log4j] Potential simplification to java9 builds?

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 wrote: > > I kind of doubt it. Logging runs up against this primarily beca

Re: [Log4j] Potential simplification to java9 builds?

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

Re: [Log4j] Potential simplification to java9 builds?

Maven and Ant are a couple places that likely needed custom solutions, but probably not applicable here. Maybe something in Commons? I tried looking at a few random projects, but I'm not seeing anything. Spring Framework might have something. On Sun, 17 May 2020 at 13:03, Volkan Yazıcı wrote: > >

Re: [Log4j] Potential simplification to java9 builds?

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 wrote: > > I was playing around

Re: [Log4j] Potential simplification to java9 builds?

Yikes, that sounds similar to OSGi. Adding modules makes testing into more of an integration exercise since traditional JUnit usage assumes a flat class path. On Sun, May 17, 2020 at 00:10 Ralph Goers wrote: > I played around with this today. I don’t think it is possible to make the > tests work

Re: [Log4j] Potential simplification to java9 builds?

I played around with this today. I don’t think it is possible to make the tests work. The reason is that from what I understand the multi-release format only works when the classes are packaged in a jar, which hasn’t happened when the tests are compiled. This causes the compile to fail since it

[Log4j] Potential simplification to java9 builds?

I was playing around with the pom a little bit yesterday when I came across a relatively new maven-compiler-plugin configuration element called 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