Hi! The issue of slf4j 1.x vs 2.x compatibility has recently come up on Avatica.
While 1.x and 2.x are compatible as far as the logging API is concerned, they are incompatible on the backend / adapter side. Traditionally, the (discontinued) hbase-client uberjar has shipped both slf4j, the adapter, and the logging backend. With hbase-embedded-client, we've removed the adapter and the backend from the uberjar, but we kept slf4j-api in it. The lesser problem is that we may effectively replace the application's slf4-api 1.x library with ours, which may be older and buggier. The bigger problem is that we are locking users to slf4j1.x, as having both slf4j 1.x and 2.x libraries on the classpath does not work reliably. See https://www.slf4j.org/faq.html#changesInVersion200 for details. The solution is very simple, we simply need to provide an uberjar which does not include slf4j-api. We can do it in one of two ways, neither is ideal: - Add a new uberjar, which is the same as an existing one (say, hbase-client-lite), but does not include the slf4j API. The problem with this is that even the "lite' uberjar is 140MB, and we already build three of them, each taking ~10 minutes to build, so this would bloat our assembly, and build times. - Change one of the existing uberjars, preferably phoenix-client-lite, and remove slf4j-api from it. This would be an incompatible change, but we avoid bloating the assembly and the build time. I feel that phoenix-client-lite is new enough (and few enough people know that it even exists) that this probably won't break a lot of existing use cases, (also the fix is as easy as adding slfj4-api to the classpath). I'm leaning towards the second option. WDYT ?
