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
