@Erick assign me a (not too large) dir... I'll help. On Mon, May 11, 2020 at 11:33 AM David Smiley <david.w.smi...@gmail.com> wrote:
> My proposal to disregard entire classes of warnings was intended to be a > short term strategy and not long term. It allows you to fix some problems > completely before moving onto others. Additionally, we can tweak the > linter settings per-module. The final end state in the future is not to > have such linter customizations. > > ~ David > > > On Mon, May 11, 2020 at 11:22 AM Mike Drob <md...@apache.org> wrote: > >> 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 >>>> >>>> -- http://www.needhamsoftware.com (work) http://www.the111shift.com (play)
