Re: Cleaning up the code

[Erick Erickson]

Weekends are when I might be devoting some time to this

Are there any more granular ways to suppress some warnings than at the
method level? We have lots of places where we, say, open a SolrCore
and don't close it, it's added to a list and closed later which is
correct behavior so needs to be suppressed.

Second question. I'm having some trouble making IntelliJ report lint
WARNINGS for "resource leak". In fact, looking over the options I
don't see where that's even a specific option in xlint. Any pointers
on where this is being generated? I see how to add xlint flags to
"recompile this file" in IntelliJ but resource leaks aren't being
reported

Thanks,
Erick

On Thu, Feb 1, 2018 at 11:04 AM, Erick Erickson  wrote:
> Great, thanks! Half the battle is often knowing it's possible
>
> On Thu, Feb 1, 2018 at 10:48 AM, Robert Muir  wrote:
>> Yes it is important to do it incrementally.
>>
>> You can override ant properties in specific modules, by defining them
>> to be something stricter before importing them from somewhere else.
>> For example, analysis/icu has no warnings, so override the default
>> javac.args at the very top, before it "imports" the rest of the build.
>>
>> diff --git a/lucene/analysis/icu/build.xml b/lucene/analysis/icu/build.xml
>>
>> +  
>>
>>
>> Now the build will fail if someone introduces a warning into that
>> module. and you can move on to the next one.
>> Quick and dirty explanation but you get the idea...
>>
>>
>> On Thu, Feb 1, 2018 at 1:34 PM, Erick Erickson  
>> wrote:
>>> You've seen a couple of JIRAs about cleaning up precommit lint
>>> warnings, and Robert mentioned compiler warnings which I totally agree
>>> with.
>>>
>>> It's just a _lot_ of code to wade through, and it'll be depressing to
>>> fix up something and have similar stuff creep back in. It'll take
>>> quite some time to clean them _all_ up, so there'll be quite a window
>>> for backsliding.
>>>
>>> Is there a way to have precommit and build fail for specific parts of
>>> the code? Let's claim we fix up all the precommit warnings in
>>> .../solr/core. It'd feel a lot more like progress if we could then
>>> have any _future_ precommit lint warnings in .../solr/core fail
>>> precommit even if, say, .../solr/contrib still had a bunch.
>>>
>>> Ditto for compiler warnings etc. As you can tell, I'm looking for help
>>> ;) Or even better "it's already in place if you'd just look"
>>>
>>> How this plays with different versions of Java I don't quite know. We
>>> may run into some stuff with Java 9 that weren't reported in Java 8
>>> and the like so I suspect turning failures on and off based on the JDK
>>> might be necessary.
>>>
>>> Erick
>>>
>>> -
>>> 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
>>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Cleaning up the code

[Erick Erickson]

Great, thanks! Half the battle is often knowing it's possible

On Thu, Feb 1, 2018 at 10:48 AM, Robert Muir  wrote:
> Yes it is important to do it incrementally.
>
> You can override ant properties in specific modules, by defining them
> to be something stricter before importing them from somewhere else.
> For example, analysis/icu has no warnings, so override the default
> javac.args at the very top, before it "imports" the rest of the build.
>
> diff --git a/lucene/analysis/icu/build.xml b/lucene/analysis/icu/build.xml
>
> +  
>
>
> Now the build will fail if someone introduces a warning into that
> module. and you can move on to the next one.
> Quick and dirty explanation but you get the idea...
>
>
> On Thu, Feb 1, 2018 at 1:34 PM, Erick Erickson  
> wrote:
>> You've seen a couple of JIRAs about cleaning up precommit lint
>> warnings, and Robert mentioned compiler warnings which I totally agree
>> with.
>>
>> It's just a _lot_ of code to wade through, and it'll be depressing to
>> fix up something and have similar stuff creep back in. It'll take
>> quite some time to clean them _all_ up, so there'll be quite a window
>> for backsliding.
>>
>> Is there a way to have precommit and build fail for specific parts of
>> the code? Let's claim we fix up all the precommit warnings in
>> .../solr/core. It'd feel a lot more like progress if we could then
>> have any _future_ precommit lint warnings in .../solr/core fail
>> precommit even if, say, .../solr/contrib still had a bunch.
>>
>> Ditto for compiler warnings etc. As you can tell, I'm looking for help
>> ;) Or even better "it's already in place if you'd just look"
>>
>> How this plays with different versions of Java I don't quite know. We
>> may run into some stuff with Java 9 that weren't reported in Java 8
>> and the like so I suspect turning failures on and off based on the JDK
>> might be necessary.
>>
>> Erick
>>
>> -
>> 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
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Cleaning up the code

[Robert Muir]

Yes it is important to do it incrementally.

You can override ant properties in specific modules, by defining them
to be something stricter before importing them from somewhere else.
For example, analysis/icu has no warnings, so override the default
javac.args at the very top, before it "imports" the rest of the build.

diff --git a/lucene/analysis/icu/build.xml b/lucene/analysis/icu/build.xml
   
+  
   

Now the build will fail if someone introduces a warning into that
module. and you can move on to the next one.
Quick and dirty explanation but you get the idea...


On Thu, Feb 1, 2018 at 1:34 PM, Erick Erickson  wrote:
> You've seen a couple of JIRAs about cleaning up precommit lint
> warnings, and Robert mentioned compiler warnings which I totally agree
> with.
>
> It's just a _lot_ of code to wade through, and it'll be depressing to
> fix up something and have similar stuff creep back in. It'll take
> quite some time to clean them _all_ up, so there'll be quite a window
> for backsliding.
>
> Is there a way to have precommit and build fail for specific parts of
> the code? Let's claim we fix up all the precommit warnings in
> .../solr/core. It'd feel a lot more like progress if we could then
> have any _future_ precommit lint warnings in .../solr/core fail
> precommit even if, say, .../solr/contrib still had a bunch.
>
> Ditto for compiler warnings etc. As you can tell, I'm looking for help
> ;) Or even better "it's already in place if you'd just look"
>
> How this plays with different versions of Java I don't quite know. We
> may run into some stuff with Java 9 that weren't reported in Java 8
> and the like so I suspect turning failures on and off based on the JDK
> might be necessary.
>
> Erick
>
> -
> 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

Cleaning up the code

[Erick Erickson]

You've seen a couple of JIRAs about cleaning up precommit lint
warnings, and Robert mentioned compiler warnings which I totally agree
with.

It's just a _lot_ of code to wade through, and it'll be depressing to
fix up something and have similar stuff creep back in. It'll take
quite some time to clean them _all_ up, so there'll be quite a window
for backsliding.

Is there a way to have precommit and build fail for specific parts of
the code? Let's claim we fix up all the precommit warnings in
.../solr/core. It'd feel a lot more like progress if we could then
have any _future_ precommit lint warnings in .../solr/core fail
precommit even if, say, .../solr/contrib still had a bunch.

Ditto for compiler warnings etc. As you can tell, I'm looking for help
;) Or even better "it's already in place if you'd just look"

How this plays with different versions of Java I don't quite know. We
may run into some stuff with Java 9 that weren't reported in Java 8
and the like so I suspect turning failures on and off based on the JDK
might be necessary.

Erick

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org