I agree with the one warning at a time approach. That one seems most feasible to take piecemeal
On Mon, May 11, 2020 at 10:19 AM Andras Salamon <andras.sala...@melda.info> wrote: > Hi, > > We have quite a few warnings, it would be difficult to fix them at once. > Checking one directory (or warning type) and handling 10-20 warnings at the > same time seems more reasonable. > > There are two umbrella jiras for that: > https://issues.apache.org/jira/browse/SOLR-10778 and > https://issues.apache.org/jira/browse/LUCENE-7907 > > I have two jiras in patch-available status: > > https://issues.apache.org/jira/browse/LUCENE-9323 > https://issues.apache.org/jira/browse/SOLR-14266 > > Andras > > On Mon, May 11, 2020 at 4:28 PM Erick Erickson <erickerick...@gmail.com> > wrote: > >> Gus: >> >> When it comes to actually removing the necessity of suppresswarnings >> IntelliJ makes a lot of this much easier. The issue is that it’s too much >> work for any one person to have a hope of doing in any reasonable period >> without introducing errors. >> >> There are just too many warnings for one person to have a hope of >> thinking carefully about all of them, so my strategy is to stop adding to >> the problem, raise awareness when it happens etc. I think to remove the >> necessity for SuppressWarnings will require extensive work, best approached >> over time, not in a huge wodge. >> >> Best, >> Erick >> >> > On May 11, 2020, at 9:25 AM, Gus Heck <gus.h...@gmail.com> wrote: >> > >> > I typically battle warnings by conquering one file/directory at a >> time... And letting Intellij take me from warning to warning with F2 key >> really really really speeds things up. This is a wider set than compiler >> warnings, but you can customize it, and many of the additional warnings are >> auto-solvable (things like redundant initializers for variables that are >> already assigned before use), so the extra work is more than paid for by >> the reduction in transition time. The key one to think carefully about is >> the one that wants to minimize access, which is great for new classes, >> dangerous for released classes. Perhaps turn that warning off in >> intellij... >> > >> > On Mon, May 11, 2020 at 8:14 AM Atri Sharma <a...@apache.org> wrote: >> > +1 to Erick’s proposal. >> > >> > I hate the number of warnings we get — we should still be formulating >> some sort of a strategy to fix them. >> > >> > Atri >> > >> > On Mon, 11 May 2020 at 17:09, Erick Erickson <erickerick...@gmail.com> >> wrote: >> > Just disabling the warning globally nothing to prevent more being >> added. Take raw types. They’re a compromise allowed by the java compiler >> explicitly to be able to continue to use older binaries written before (or >> without) generics. But take a look at SolrQueryResponse for instance. We >> explicitly declare: >> > >> > protected NamedList<Object> values = new SimpleOrderedMap<>(); >> > >> > but then declare a method: >> > >> > public NamedList getValues() { return values; } >> > >> > This is just bad practice. >> > >> > I don’t mind the grunt work, keeps me from stupid surfing. I’m >> proposing that I fix what’s easy, and suppress the rest. >> > >> > It might have been clearer if I’d said “Then start failing builds on >> any new warnings of these types”. >> > >> > Oh, and I’m also thinking of changing my BadApple report to flag when >> new SuppressWarnings are introduced and then nag people about new ones. >> > >> > >> > >> > > On May 10, 2020, at 11:43 PM, David Smiley <david.w.smi...@gmail.com> >> wrote: >> > > >> > > Can't we customize the linting to disregard entire categories of >> certain warnings for now? This makes your task manageable. >> > > https://discuss.gradle.org/t/recompile-with-xlint-parameters/25279 >> > > >> > > ~ David >> > > >> > > >> > > On Sun, May 10, 2020 at 10:41 PM Erick Erickson < >> erickerick...@gmail.com> wrote: >> > > I’m really struggling with what to do with compiler warnings, >> particularly all the rawtypes and unchecked warnings. >> > > >> > > On the one hand, the simple mechanical thing to do would be to >> SuppressWarnings on each one that exists presently. Frankly that feels >> pretty useless; that would preserve poor code forever. >> > > >> > > OTOH, actually _fixing_ the issues to not have, say, rawtypes is >> going to be time consuming and error-prone. Especially since I don’t really >> understand all the nuances yet and learning them one by one will introduce >> serious errors without doubt. >> > > >> > > So here’s what I propose. Even though it feels useless, just >> SuppressWarnings on anything that’s not a simple fix. Then start failing >> builds on these warnings to catch any that come in in future. At least that >> way there’ll be some incentive to keep the code from getting _worse_, >> although people will still be able to just add SuppressWarnings to the mix >> I suppose. >> > > >> > > The number of raw NamedList member variables we have is overwhelming >> all by itself…. >> > > >> > > Comments? >> > > >> > > >> > > --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > > For additional commands, e-mail: dev-h...@lucene.apache.org >> > > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> > >> > -- >> > Regards, >> > >> > Atri >> > Apache Concerted >> > >> > >> > -- >> > http://www.needhamsoftware.com (work) >> > http://www.the111shift.com (play) >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >>
