Following up on the discussion from the community sync meeting. Right now,
Iceberg test code is in the 3rd row in the table pasted below. With the
recent Avro 1.12 upgrade (and slf4j 2.x), the main code is also affected.
That means downstream applications (Spark, Trino, Flink, ...) may run into
the same situation when upgrading to the next Iceberg 1.7 release.

[image: image.png]

>From the slf4j doc, it seems that *slf4j 2.x API is backward compatible as
long as provider/binding is updated to 2.x too*.
https://www.slf4j.org/faq.html#changesInVersion200

We have two options
1. Exclude the slf4j 2.x transitive dependency from Avro 1.12. but we would
need to be comprehensive on forcing the slf4j dependency version resolution
to 1.x everywhere until Iceberg is ready to move forward to slf4j 2.x.
2. Move forward with slf4j 2.x now with a clear callout in the 1.7 release
notes.

First option is the more conservative approach and defer the slf4j 2.x
upgrade decision to the downstream applications. But it will add a little
burden to make sure future dependency upgrades don't bring in slf4j 2.x
transitively. Maybe we can leverage the force resolution from Gradle?

configurations.all {
  resolutionStrategy {
    force 'org.slf4j:slf4j-api:1.7.35'
  }
}


Thanks,
Steven

SLF4J 2.0 stable release was announced *2 years ago*:
https://mailman.qos.ch/pipermail/announce/2022/000176.html. It explained
binary compatibility.

"Mixing different versions of slf4j-api.jar and SLF4J provider can cause
problems. For example, if you are usingslf4j-api-2.0.0.jar, then you should
also use slf4j-simple-2.0.0.jar, using slf4j-simple-1.5.5.jar will not
work."

More notes from slf4j FAQ page.

"SLF4J 2.0.0 incorporates an optional fluent api
<https://www.slf4j.org/manual.html#fluent>. Otherwise, there are no client
facing API changes in 2.0.x. For most users, upgrading to version 2.0..x
should be a drop-in replacement, as long as the logging provider is updated
as well.

>From the clients perspective, the SLF4J API, more specifically the org.slf4j
 package, is backward compatible for all versions. This means that you can
upgrade from SLF4J version 1.0 to any later version without problems. Code
compiled with *slf4j-api-versionN.jar* will work with
*slf4j-api-versionM.jar* for any versionN and any versionM. *To date,
binary compatibility in slf4j-api has never been broken."*


On Mon, Sep 9, 2024 at 9:22 AM Steven Wu <stevenz...@gmail.com> wrote:

> Bump the thread to bring the awareness of the issue and implication of
> slf4j 2.x upgrade.
>
> On Mon, Aug 26, 2024 at 12:24 PM Steve Zhang
> <hongyue_zh...@apple.com.invalid> wrote:
>
>> I believe dependabot tried to upgrade self4j to 2.x in [1] but JB
>> mentioned there's -1 on this upgrade, maybe he has more context.
>>
>> [1]https://github.com/apache/iceberg/pull/9688
>>
>> Thanks,
>> Steve Zhang
>>
>>
>>
>> On Aug 24, 2024, at 7:37 PM, Steven Wu <stevenz...@gmail.com> wrote:
>>
>> Hi,
>>
>> It seems that test logging is broken in many modules (like core, flink)
>> because slf4j-api was upgraded to 2.x while slf4j-simple provider is still
>> on 1.7. I created a PR that upgraded slf4j-simple testImplementation to 2.x
>> for all subprojects.
>>
>> https://github.com/apache/iceberg/pull/11001
>>
>> That fixed the test logging problem (e.g. TestInMemoryCatalog). You can
>> find more details in the PR description. Test logging seems to have been
>> broken for a while (from 1.4). But those dep problems have been for *test
>> runtime only*.
>>
>> Recent change [1] on Avro 1.12.0 introduced slf4j-api 2.x change for
>> runtime, as verified by the cmd below on the *main branch*.
>>
>> ./gradlew -q :iceberg-core:dependencyInsight --dependency slf4j-api
>> --configuration runtimeClasspath
>>
>> This thread is to raise awareness on the slf4j-api dep change to 2.x as
>> downstream projects/applications can be affected. Looking forward to
>> feedback on the path forward.
>>
>>    1. continue the current upgrade path and document the slf4j-api 2.x
>>    change in the next 1.7 release. But we need to be cautious of not porting
>>    the Avro 1.12.0 / slf4j-api 2.x change to the 1.6 branch.
>>    2. exclude slf4j-api transitive deps from Avro and other test deps so
>>    that Iceberg stays on slf4j 1.7. If that is the direction to go, we won't
>>    need  PR #11001.
>>
>>
>> Thanks,
>> Steven
>>
>> [1] https://github.com/apache/iceberg/pull/10879
>>
>>
>>

Reply via email to