Re: Log4j 3.x release

Hi Ralph, On Sun, 4 Jun 2023 at 05:28, Ralph Goers wrote: > I believe I have finished the work necessary to successfully perform a > release of Log4j 3.x. I am not aware of any items that MUST be done for a > 3.0.0-alpha1 release. If any of you are please let me know. I will wait a few > days

Call for Presentations, Community Over Code Asia 2023

You are receiving this message because you are subscribed to one more more developer mailing lists at the Apache Software Foundation. The call for presentations is now open at "https://apachecon.com/acasia2023/cfp.html";, and will be closed by Sunday, Jun 18th, 2023 11:59 PM GMT. The event will b

Re: Log4j 3.x release

I’m still working on the updated DI system in a branch, but it’s not a _must have_ for the first alpha. As we did with 2.0, I expect that various levels of API stability (besides log4j-api) won’t be guaranteed until we hit the release candidate phase for 3.0.0. Since the DI stuff is still in flu

[log4j] Base Java version requirements for the future?

Piotr raised an interesting question recently which deserves a dedicated thread here: what should our strategy be for supporting various versions of Java? Our current strategy is essentially Java 8 for 2.x and Java 11 for 3.x, but with projects like Spring pushing Java 17 as a base requirement a

Re: [log4j] Base Java version requirements for the future?

I feel we should base 3.0 on Java 11 and later go to 17, then 21, these all being Java LTS versions. >From what I see at work and in the wild, the move from Java 8 to 11 was a big deal. Sure, we are looking at 17 at work for the future but there is no big rush because on some of the OSs/customers

Re: [log4j] Base Java version requirements for the future?

Since you are asking about strategy, mine has always been: 1. Use the lowest JDK version that still has a user base of over 10% or 2. Use the minimum JDK version that meets the requirements for what the code base targets. For a long time I attempted to stick to using JDK 8 for 3.x but at some po

Re: [log4j] Base Java version requirements for the future?

I don't have a strong preference for the bytecode version we "target"; 11 or 17 is fine. But I would like to point out that we should move the compiler requirement to Java 17 and preferably always stick to the latest LTS as much as possible. On Mon, Jun 5, 2023 at 6:33 PM Matt Sicker wrote: > Pi

Re: [log4j] Base Java version requirements for the future?

The latest LTS always view is not realistic if you want users to migrate to our latest version. My experience is that this will only achieve excluding apps from migrating because updating the underlying Java platform is non-trivial for larger enterprise grade stacks. Gary On Mon, Jun 5, 2023, 14:

Re: [log4j] Base Java version requirements for the future?

Gary, I think we are not on the same page. I am talking about the "compiler" version, not the "target" version. The version developers use to compile the code, not to run the generated bytecode. We can compile with 17, yet target 11, etc. For instance, both `logj4-tools` and `log4j-transform` get

[log4j] Changing `LevelRangeFilter` defaults (breaking change!)

In #1503 , I have replaced `minLevel`/`maxLevel` of `LevelRangeFilter` from `ERROR`/`ERROR` to `OFF`/`ALL` and added documentation. Since this is a breaking change, I would appreciate it if somebody else could review it and press the merge button.

Re: [log4j] Base Java version requirements for the future?

Ah, ok, right, for the tooling to build the software, we should use whatever we want, it should not affect the end product. Gary On Mon, Jun 5, 2023, 16:19 Volkan Yazıcı wrote: > Gary, I think we are not on the same page. I am talking about the > "compiler" version, not the "target" version. Th

Re: [log4j] Base Java version requirements for the future?

IMO the desired case is that I can use Java 11 to build and you can use Java 17. Unless I am forced to do otherwise I will always use the target version for the release build. For example, I wouldn’t want the changeling support to require Java 17 as then I would be unable to migrate Flume to us

Re: [log4j] Base Java version requirements for the future?

Hi Gary, On Mon, 5 Jun 2023 at 18:57, Gary Gregory wrote: > From what I see at work and in the wild, the move from Java 8 to 11 was a > big deal. Sure, we are looking at 17 at work for the future but there is no > big rush because on some of the OSs/customers we deal with, going to Java > 17 requ

Re: [log4j] Possible concurrency bug in DatePatternConverter.formatWithoutThreadLocals(Instant,StringBuilder)?

Hi Stephan, On Sun, 28 May 2023 at 14:00, Stephan Markwalder wrote: > > Experimentally using a simple non-volatile class field for the cache > works better: the fact that multiple threads see a different cached value > is actually an advantage here. Also apparently the cost of syncing the > cache