Re: Log4j 3.x release

[Piotr P. Karwasz]

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 for feedback on this to give you all a chance to review things.

I am still concerned about possible regressions, but since I haven't
done any work on that for a couple of months, I am Ok with releasing
`alpha1`.

Let me just migrate `log4j-jakarta-smtp` to `main` and we are ready to go.

Piotr

Call for Presentations, Community Over Code Asia 2023

[Rich Bowen]

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 be held in Beijing, China, August 18-20, 2023.

We are looking for presentations about anything relating to Apache
Software Foundation projects, open-source governance, community, and
software development.
In particular, this year we are building content tracks around the
following specific topics/projects:

AI / Machine learning
API / Microservice
Community
CloudNative
Data Storage & Computing
DataOps
Data Lake & Data Warehouse
OLAP & Data Analysis
Performance Engineering
Incubator
IoT/IIoT
Messaging
RPC
Streaming
Workflow / Data Processing
Web Server / Tomcat

If your proposed presentation falls into one of these categories,
please select that topic in the CFP entry form. Or select Others if
it’s related to another topic or project area.

Looking forward to hearing from you!

Willem Jiang, and the Community Over Code planners

Re: Log4j 3.x release

[Matt Sicker]

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 flux, I expect that 
to change a bit over subsequent releases, but that’s not a blocker to getting a 
first alpha.

> On Jun 3, 2023, at 10:28 PM, 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 for feedback on this to give you all a chance to review things.
> 
> Ralph

[log4j] Base Java version requirements for the future?

[Matt Sicker]

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 and Java 21 (the 
latest LTS release) coming out in September, we may want to devise a version 
support strategy.

As for relevant features in newer releases, we can rely on multi-version jars 
to support specific APIs, but even some of the more relevant ones like scoped 
values and string templates are still in preview mode as of version 21.

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

[Gary Gregory]

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 we deal with, going to Java
17 requires an OS upgrade, which is a huge ask.

So, one LTS at a time IMO.

Gary

On Mon, Jun 5, 2023, 12:33 Matt Sicker  wrote:

> 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
> and Java 21 (the latest LTS release) coming out in September, we may want
> to devise a version support strategy.
>
> As for relevant features in newer releases, we can rely on multi-version
> jars to support specific APIs, but even some of the more relevant ones like
> scoped values and string templates are still in preview mode as of version
> 21.

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

[Ralph Goers]

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 point 
it just became unworkable. Trying to get fully compliant JPMS modules while 
sticking with multi-release stuff what becoming impossible. That necessitated a 
move to Java 11, but we have no other features or dependencies that require a 
newer JDK version.

https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem shows 
the following usage stats:

Java 8 - 33%
Java 11 - 56%
Java 17 - 9%

Given those stats a switch to requiring Java 17 as the base version seems 
pretty premature.

Ralph

> On Jun 5, 2023, at 9:31 AM, Matt Sicker  wrote:
> 
> 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 and Java 
> 21 (the latest LTS release) coming out in September, we may want to devise a 
> version support strategy.
> 
> As for relevant features in newer releases, we can rely on multi-version jars 
> to support specific APIs, but even some of the more relevant ones like scoped 
> values and string templates are still in preview mode as of version 21.

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

[Volkan Yazıcı]

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:

> 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
> and Java 21 (the latest LTS release) coming out in September, we may want
> to devise a version support strategy.
>
> As for relevant features in newer releases, we can rely on multi-version
> jars to support specific APIs, but even some of the more relevant ones like
> scoped values and string templates are still in preview mode as of version
> 21.

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

[Gary Gregory]

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:39 Volkan Yazıcı  wrote:

> 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:
>
> > 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
> > and Java 21 (the latest LTS release) coming out in September, we may want
> > to devise a version support strategy.
> >
> > As for relevant features in newer releases, we can rely on multi-version
> > jars to support specific APIs, but even some of the more relevant ones
> like
> > scoped values and string templates are still in preview mode as of
> version
> > 21.
>

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

[Volkan Yazıcı]

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 compiled with
17, yet target 8. Hence 8 users can still consume them.

On Mon, Jun 5, 2023 at 10:00 PM Gary Gregory  wrote:

> 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:39 Volkan Yazıcı  wrote:
>
> > 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:
> >
> > > 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
> > > and Java 21 (the latest LTS release) coming out in September, we may
> want
> > > to devise a version support strategy.
> > >
> > > As for relevant features in newer releases, we can rely on
> multi-version
> > > jars to support specific APIs, but even some of the more relevant ones
> > like
> > > scoped values and string templates are still in preview mode as of
> > version
> > > 21.
> >
>

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

[Volkan Yazıcı]

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?

[Gary Gregory]

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. 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 compiled with
> 17, yet target 8. Hence 8 users can still consume them.
>
> On Mon, Jun 5, 2023 at 10:00 PM Gary Gregory 
> wrote:
>
> > 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:39 Volkan Yazıcı  wrote:
> >
> > > 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:
> > >
> > > > 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
> > > > and Java 21 (the latest LTS release) coming out in September, we may
> > want
> > > > to devise a version support strategy.
> > > >
> > > > As for relevant features in newer releases, we can rely on
> > multi-version
> > > > jars to support specific APIs, but even some of the more relevant
> ones
> > > like
> > > > scoped values and string templates are still in preview mode as of
> > > version
> > > > 21.
> > >
> >
>

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

[Ralph Goers]

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 use it.

Ralph

> On Jun 5, 2023, at 1:19 PM, 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. 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 compiled with
> 17, yet target 8. Hence 8 users can still consume them.
> 
> On Mon, Jun 5, 2023 at 10:00 PM Gary Gregory  wrote:
> 
>> 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:39 Volkan Yazıcı  wrote:
>> 
>>> 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:
>>> 
 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
 and Java 21 (the latest LTS release) coming out in September, we may
>> want
 to devise a version support strategy.
 
 As for relevant features in newer releases, we can rely on
>> multi-version
 jars to support specific APIs, but even some of the more relevant ones
>>> like
 scoped values and string templates are still in preview mode as of
>>> version
 21.
>>> 
>> 

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

[Piotr P. Karwasz]

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 requires an OS upgrade, which is a huge ask.

Thank you for the insight. The reason I brought this topic up is that:

 * the support for JDK 11 stops in September (security support will continue),
 * Spring is using Java 17,
 * I had the wrong impression that the Java world polarized between
those that will stick to Java 8 forever (and Java EE 8) and those that
use the latest LTS. Apparently I was wrong.

Java 17 does not bring anything we can not live without. I mentioned
switching to it, because I found a couple of classes that could be
`sealed`.

Piotr

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

[Piotr P. Karwasz]

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
> cached value among threads is not compensated by a smaller number of cache
> misses.
>
> When I look at code where thread-safety has been given up for performance,
> I'm always very much scared of potential side-effects like partially
> initialized Java objects made visible to other threads. In this specific
> case, the fields of `CachedTime` are non-final and non-volatile. Wouldn't
> this mean that another thread could read their uninitialized valued? Due to
> the method's logic, this would probably not be a big deal for
> `epochSeconds` and `nanoOfSecond` (just a cache miss), but an unexpected
> null value read from the field `formatted` could cause a new bug. I assume
> this could be fixed with an extra null-check, or by making all fields in
> `CachedTime` final. But it is a tricky territory nevertheless, and every
> future code change has to be reviewed very carefully in this regard.

Thanks for the review, I'll finalize the fields of the `CachedTime`
class. If you have additional remarks feel free to review the PR
directly: reviews are not restricted to the core developers.

Piotr