Strategy for supporting both Java EE and Jakarta EE in logback

[ceki]

Strategy for supporting both Java EE and Jakarta EE in logback distributions

Given that our downstream users are likely to use either Java EE or (in the javax namespace) and and Jakarta EE (in the jakarta namespace) in their projects, we feel that it is important for logback to support both alternatives.

Logback consists of 3 modules, namely logback-core, logback-classic and logback-access, which depend on either {javax|jakarta}.mail or {javax|jakarta}.servlet.

Currently logback 1.2.x and 1.3.0-SNAPSHOT support Java EE, while 1.3.0-beta0 supported Jakarta EE (reverted to Java EE in 1.3.0-SNAPSHOT).

1. One idea would be to maintain two branches with each branch supporting one of Java EE or Jakarta EE.
2. Another closely related idea would be to support Java EE in logback 1.3.x and Jakarta EE in logback 1.4.x
3. Since Java EE and Jakarta EE live in different packages, logback could have two implementations say SMTPAppender (using the javax namespace) and JakartaSMTPAppender.

Are their better alternatives?

Update: Logback will ship in two nearly identical versions, namely 1.3 and 1.4 differing in the following ways:

Logback version	github branch	SLF4J version	JDK	EE (enterprise edition)
1.3	branch_1.3.x	2.0	8	Java EE
1.4	master	2.0	11	Jakarta EE

[ceharris]

Would it be feasible to create a thin abstraction layer to decouple those modules from direct dependence on the Servlet API? Perhaps just a collection of interfaces that could be implemented using the APIs from both namespaces, and then a logback user could simply include the right EE API adapter (e.g. logback-java-ee.jar or logback-jakarta-ee.jar). Conceptually similar to the way slf4j adapts to the logging provider.

[ceharris]

@ceki I'd be surprised if there weren't some purpose-built adapters for some of the EE APIs in other open source libraries like logback, but I don't see anything that claims to do that in a general way.

I guess I was imagining that there's a small enough cross section of the EE API used in -core and -classic that it would be feasible to create adapter interfaces for those needs. Maybe for -access, a more feasible approach would be to factor out the (admittedly small) part of that module that could be shared by separately maintained -access-jakarta-ee and -access-java-ee modules. There'd still be a lot of unavoidable duplication in those separate modules, but it might be less than the duplication resulting from an approach that uses branches.

[ceki]

@ceharris I think targeting logback 1.3 for Java EE and logback 1.4 for Jakarta EE, while not great for the project maintainers, is the clearest and easiest approach from the end-user's point of view. It is also conceptually the simplest to explain.

[ceharris]

There's certainly ample precedence for using that approach.

[mohanaraosv]

The above approach will be nice even when the Javax package reaches EOL.

[zUniQueX]

@ceharris I think targeting logback 1.3 for Java EE and logback 1.4 for Jakarta EE, while not great for the project maintainers, is the clearest and easiest approach from the end-user's point of view. It is also conceptually the simplest to explain.

That's also the way other library authors deal with it. The only consideration would be to plan a major version upgrade for the Jakarta EE namespace change.

[davidkarlsen]

Would maybe the easiest (and less magic) option be to have the core-code/"business logic" in -core, and have thin delegating jars/layers which are either javax or jakarta based?

[brenuart]

My two cents...

For the servlet-api, would it be possible to provide two distinct implementations of the related Logback components, one for Java EE and the other for Jakarta EE, and let the user choose to use one or the other in his configuration?
These dependencies are optional (or compile scope) so the user must already explicitly add them to his project.
The idea is to declare them both as optional in the logback project so they are both on the compile/test classpath. This way both implementations can live inside the same logback-access jar without requiring distinct artefacts.

A similar approach can be followed for the mail API. An alternative here is to introspect the class path at runtime and dynamically choose which implementation to use (or delegate). That would be "transparent" for the user.