This’ll be a bit tricky as long as we have Java required 11 on master and Java 8 on 8x, we’ll have to sort out the deprecations due to the JDK .vs. everything else.
That said, +1 to fixing this up, it’s been on my TODO list for, oh, 2 years or so, but keeps sliding. A hackathon would be a great venue since there’ll be a zillion changes. Is there a way we can, once we have all the deprecation warnings out of a file, somehow fail precommit/test/build/whatever when deprecations sneak back in? It’d have to be on a file-by-file basis I’d guess, but that way we could keep from backsliding. You can convince IntelliJ (and I’m sure Eclipse) to show deprecation warnings when you pick the “recompile this file” which I recently started using. Ditto with precommit warnings…. > On Dec 18, 2019, at 4:48 AM, Jan Høydahl <jan....@cominvent.com> wrote: > > Hi > > Our project compiles and runs with tons of deprecation warnings. > > Recently when working on SOLR-14106 and SOLR-14105 we found that there has > been jetty deprecation warnings in the logs ever since the 8.2 release, and > these were early warnings that something was wrong, so not surprisingly, to > get SSL working again in 8.5 the fix was to remove use of deprecated classes > in Jetty. > > It may be a too ambitious goal to remove all use of deprecated APIs. But what > about doing a hackaton to try to nail many of them! I bet we find some real > bugs during that process as well. > > Jan --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
