Next Log4cxx Major release thoughts

[rm5248]

Whenever we do a new major release of Log4cxx(also breaking ABI compatibility), what should we do? My current thoughts are as follows:

1. Remove APR(or at the very minimum make it optional). I would like to see the core library be in just standard C++
2. What should the minimum C++ version be? C++20 includes std::source_location, while C++23 includes std::stacktrace
3. add constexpr to a bunch of functions? I've been reading up on how constexpr works, so perhaps some more thoughts on this later
4. Are there certain operations that could be better handled by newer C++ features? For example, could we make the API more usable by removing the LOG4CXX_DEBUG family of macros and instead use variadic templates?
5. Do we have any areas in the code where performance is a known problem, and could a redesign help to eliminate performance issues?
6. What about C++ modules? Are traditional headers ever going away?

Features to definitely keep:

1. Static declaration of loggers. While this does lead to undefined behavior at times(generally when exiting), being able to statically declare a logger is very important to me.

What other thoughts do people have?

In terms of timelines, I wouldn't expect a new version to be done before the end of 2026, so this is a pretty long timeline.

[swebb2066]

Remove APR(or at the very minimum make it optional). I would like to see the core library be in just standard C++

I do not believe it is yet possible to remove the APR dependency as it provides essential functionality (e.g. apr_file_write, apr_proc_create) that is not yet in the C++ standard library.

Are there certain operations that could be better handled by newer C++ features? For example, could we make the API more usable by removing the LOG4CXX_DEBUG family of macros and instead use variadic templates?

I suggest changing the LOG4CXX_DEBUG family of macros to require logged values be copy-constructible/move-constructible. This would allow us to implement the equivalent to "asynchronous loggers" that is already in Log4j2, and for users to see performance benefits without any code change. The LoggingEvent would need to hold a std::vector<std::function<void(MessageBuffer&)>> or similar.

[rm5248]

Remove APR(or at the very minimum make it optional). I would like to see the core library be in just standard C++

I do not believe it is yet possible to remove the APR dependency as it provides essential functionality (e.g. apr_file_write, apr_proc_create) that is not yet in the C++ standard library.

Is there a reason that we should continue to use the APR functions? I haven't looked closely, but I think for the most part the APR functions are wrappers around fopen and other C functions.

Are there certain operations that could be better handled by newer C++ features? For example, could we make the API more usable by removing the LOG4CXX_DEBUG family of macros and instead use variadic templates?

I suggest changing the LOG4CXX_DEBUG family of macros to require logged values be copy-constructible/move-constructible. This would allow us to implement the equivalent to "asynchronous loggers" that is already in Log4j2, and for users to see performance benefits without any code change. The LoggingEvent would need to hold a std::vector<std::function<void(MessageBuffer&)>> or similar.

I like that thought.

I haven't messed around with it yet, but if we want to support newer C++ standards, we could automatically create std::backtrace objects, and use std::source_location instead of the custom type that exists today. The problem with the backtrace is that I don't have any ideas on how to make it easy without a macro at the moment. The only thing I can think of is to do a fluent interface like:

logger.debug("message").withLocation().withBacktrace();

But I prefer having the macros, since that can expand into code better. The above example is similar to what flogger does.