I’ve likely made a release in the past doing the same thing, and it hasn’t
been an issue. The important thing is verifying it still compiles and runs
in Java 7 independently from the same source.
On Sun, Jun 23, 2019 at 20:55, Ralph Goers
wrote:
> Please note that this is the first time I have
Please note that this is the first time I have run a release build using Java
8. Please verify it works correctly in Java 7. I looked at the jar manifests
for core and api and they both show Java 7 as the target.
Ralph
This is a vote to release Log4j 2.12.0, the next version of the Log4j 2 project.
Please download, test, and cast your votes on the log4j developers list.
[] +1, release the artifacts
[] -1, don't release because...
The vote will remain open for 72 hours (or more if required). All votes are
I think this dates back to when Flogger was on a media blitz recently. I
remember being contacted about it, and I’d assume several of you received a
similar email. I imagine SLF4J added this API in response even though I
thought we had considered a similar API in the past.
On Sun, Jun 23, 2019 at
This looks a lot like Google Flogger[1], we may want to read through their
design (if you haven't done so already) to see if there's anything clever
they've done that we should take advantage of.
I'll take a look at the PR today.
1. https://github.com/google/flogger
On Sun, Jun 23, 2019, at
Yeah, I have thought quite a bit about this and have never been able to come up
with a solution that didn’t require modifications to Java. With the new
withLocation method it should be possible to provide a null value that gets
replaced with a constant that is generated by the annotation
It certainly sounds interesting to me, though I say that about a lot of
things (which are all interesting though!). For Java, I’d imagine we’d need
to do something at the compiler level unless there’s enough information in
the bytecode to reconstruct the proper Java source location info. If only
It would be ideal if location information could be collected at compile
time. It is constant and unchanging information after all and it seems
silly to have to dynamically calculate this at runtime.
While Java doesn’t have compile time macros I was wondering if there’s
anything else we can do.
