Tim, I'm +1 on documenting the current situation and keeping *slf4j* 2.x since there's a mitigation for most users. Accidents do happen as a lot of folks have found with *slf4j* 1.7 -> 2.0. Many just merged PR from dependabot only to find that it had more far-reaching consequences after release.
I'll update wiki [2] with the current state of affairs and recommendations like avoiding log4j 1.2.x. Maybe adding some rules for Uwe's *forbiddenapis* plugin to avoid accidentally using the new *slf4j* API to allow downgrading for *slf4j-jboss-logmanager* users. As for Java 11 my preference is to bump major version even if there wouldn't be any major changes in the Tika APIs. Maybe add an announcement on the next release (2.7.0 or 2.6.1 whichever comes first) that the next release would be 3.0.0 and will require Java 11 and 2.6.x/2.7.x will keep to Java 1.8 and contain backports for some time with explicit EoL from the start. A bit of ecosystem overview: * the New Relic report [1] this year shows that Java 11 finally overcame 1.8's share, some other reports I read had 10-15% Java 17 in production; * AFAIK *Spring Boot* 3.x will require Java 17; * *Quarkus* 3.x use java 11 for framework but use 17 in generated projects by default with an option to bump to java 17 in 3.x if their dependencies require. So, +1 for releasing 3.0.0 with java 11. Bumping to 17 seems quite radical for now but in a year or two it could be a go. [1]: https://newrelic.com/resources/report/2022-state-of-java-ecosystem [2]: https://cwiki.apache.org/confluence/display/TIKA/Logging -- Best regards, Konstantin Gribov. On Tue, Nov 8, 2022 at 2:16 PM Tim Allison <[email protected]> wrote: > Hi Konstantin, > > I didn't recognize the ramifications of this when working on > TIKA-3842. I'm sorry for this breaking change. > > I'm personally hesitant to downgrade the main branch given that > 2.5.0 has been out for a bit more than a month, and now we have 2.6.0. > > This could be further reason to go back to managing two branches [0]. > One could be a bug fix branch 2.7.x (with reverted slf4, requiring > only Java 8), and the other 2.8.x or maybe even 3.0.0 could be the > main branch (with the updated slf4j (as it currently is) and Java 11)? > > I personally don't have any breaking plans for Tika 3.x[1]. It would > not be the heavy lift for users wrt metadata and new modules that 2.x > was. I _think_ most projects I'm keeping track of now are waiting for > major version changes before requiring Java 11. > > What do you all think? > > Best, > > Tim > > [0] https://issues.apache.org/jira/browse/TIKA-3735 > [1] Except that I'd really like to clean up serialization from > tika-config.xml so that all components use the newer format. However, > we can maintain back compat without a problem until 4.x if we do > choose to go to 3.x soonish. > > > On Mon, Nov 7, 2022 at 6:54 PM Konstantin Gribov <[email protected]> > wrote: > > > > Hi, folks. > > > > Sorry, I totally missed the moment when TIKA- 3842 [1] (update slf4j to > > 2.0.x) was discussed and merged. > > > > *TL;DR: **slf4j-api *update from 1.7.x to 2.0.x in *tika-core *2.5.0 > requires > > downstream library users to update logging backend. *Tika Server* & *Tika > > Python* not affected. In most cases logging libraries have newer > compatible > > versions except *slf4j-jboss-logmanager*. Downgrading *slf4j-api* may > work > > but is potentially fragile. */TL;DR* > > > > It was **a breaking API change** for the *tika-core* and dependent > packages > > like *tika-parser-*-module*, *tika-parsers-standard-package*. > > > > Good news: > > * users of the *tika-server* and *tika-python* should not be affected at > > all; > > * users with *log4j2* as a logging backend could replace > *log4j-slf4j-impl* > > with *log4j-slf4j2-impl*; > > * users with *logback-classic* 1.2.x could update to *logback-classic* > > 1.4.x; > > * users with *log4j* 1.2.x (which is EOL since 2015 and has security > > vulnerabilities IIRC) could update to *slf4j-reload4j* 2.0.x; > > > > Users with *slf4j-jboss-logmanager* are currently out of luck and have to > > wait for a new release [2]. > > > > I'm not sure if we should rollback *slf4j* to 1.7.36 or keep going as > it's > > now and just document that 2.5.0 had a breaking change in the API. > > > > For example * Spring Boot* will make such a change on 2.x to 3.0 > > transition, *Quarkus* will likely follow a similar path since they > blocked > > bumping *slf4j* from 1.7.36 to 2.0.x. > > > > Downgrading *slf4j-api* *seems* to work in a simple case but all the > calls > > to the loggers have to be reviewed to at least be sure that there's no > > calls to fluent logging API introduced in *slf4j-api* 2.0. More in depth > > investigation is required to have more confidence that such a setup would > > work flawlessly. > > > > To downgrade *slf4j-api* one could add following block to *pom.xml* for > *Apache > > Maven* builds: > > > > ``` > > <dependencyManagement> > > <dependencies> > > <dependency> > > <groupId>org.slf4j</groupId> > > <artifactId>slf4j-api</artifactId> > > <version>1.7.36</version> > > </dependency> > > </dependencies> > > </dependencyManagement> > > ``` > > > > Similar with Gradle: > > > > ``` > > dependencies { > > constraints { > > // api or implementations depends on usage, for java-library prefer > api > > api("org.slf4j:slf4j-api") { > > version { strictly("1.7.36") } // or strictly("[1.7,1.8)") for > > dynamic version > > } > > } > > } > > ``` > > > > [1]: https://issues.apache.org/jira/browse/TIKA-3842 > > [2]: https://issues.redhat.com/browse/JBLOGGING-165 > > > > -- > > Best regards, > > Konstantin Gribov. >
