If we use the -Werror flag be sure to NOT enable all warnings and disable some of them (this makes build non-reproducible if JVM changes). So when using -Werror, we should list all warnings we want to see explicit (so no “all” warning). For Eclipse’s ECJ do the same.


In general with the Eclipse compiler we can define “per violation type” which action to take (warn or fail). But unfortunately, this does not allow suppression (as it is no longer a warning).



Uwe Schindler

Achterdiek 19, D-28357 Bremen


eMail: uwe@thetaphi.de


From: mdrob@cloudera.com [mailto:mdrob@cloudera.com] On Behalf Of Mike Drob
Sent: Wednesday, July 5, 2017 6:10 PM
To: Lucene Dev <dev@lucene.apache.org>
Cc: Christine Poerschke <cpoerschke@bloomberg.net>
Subject: Re: 10 Resource Leak warnings dated to Q2 2017


I think you can do this with the -Werror flag and supress annotating everything else.


On Wed, Jul 5, 2017 at 10:45 AM, Erick Erickson <erickerickson@gmail.com> wrote:

bq:  making precommit fail for some but not all resource leaks.
Implementation wise, how might one go about that?

No clue, hoping somebody who _does_ have clue will just say "oh, you
just specify blah blah blah" ;)

On Wed, Jul 5, 2017 at 8:39 AM, Christine Poerschke (BLOOMBERG/

LONDON) <cpoerschke@bloomberg.net> wrote:
> Hi Erick,
> Thanks for the extra context re: JavaBinCodec and SOLR-10779.
> I agree that backporting warning fixes to 6x is optional at this point and for complex fixes probably not worth the risk of introducing subtle bugs in the process.
> +1 to your idea of making precommit fail for some but not all resource leaks. Implementation wise, how might one go about that? Redirecting precommit output and post-processing it should be do-able but seems hacky ...
> Christine
> ----- Original Message -----
> From: dev@lucene.apache.org
> To: Christine Poerschke (BLOOMBERG/ LONDON), dev@lucene.apache.org
> At: 07/04/17 16:45:11
> Christine:
> I fixed the JavaBinCodec warnings in SOLR-10779 for master/7.0, but
> didn't backport to 6x. So if those warnings are creeping back in to
> the 7x code line we can take a look.
> I didn't backport to 6x since this seems to be long-term enough that
> there isn't much point, along with the feeling that we'll introduce
> problems at times in the effort and my view is that 6x is close enough
> to end of development that we shouldn't expend the effort or introduce
> instabilities. Or, put another way, I didn't want to be responsible
> for introducing bugs in 6x, 7x is fair game ;)
> Along the lines of making forward progress though.... Is it possible
> to make precommit fail for resource leaks for specific classes only?
> Or for specific files? It wouldn't be perfect, but cleaning up
> warnings for a class then having precommit fail if resource leaks came
> back in would feel less like Sisyphus.
> I'm looking for either of the following. Or both of course.
> - fail if precommit issues resource leak warnings for the _class_
> JavaBinCodec wherever it's used.
> - fail if precommit issues resource leak warnings in the _file_
> whatever.java if any resource leak warnings are found for any class.
> The first one is the one I'd probably use on the theory that one gets
> familiar with the quirks of a particular class and it's easier to
> clean up the resource leak warnings for that class than all the
> warnings that might be in a file. But that's a personal preference.
> Erick
> On Tue, Jul 4, 2017 at 3:47 AM, Christine Poerschke (BLOOMBERG/
> LONDON) <cpoerschke@bloomberg.net> wrote:
>> Hi Everyone,
>> The following list is the latest Q2 2017 portion of the dated-warnings.log file I've attached to https://issues.apache.org/jira/browse/SOLR-10778 and it was generated by the also attached shell script that correlates warnings with git commit history.
>> Any help to investigate and take care of these warnings would be appreciated. The short term goal is to not increase the number of warnings we have and in the medium to long term the goal would be to fail precommit if any warnings are detected.
>> Christine
>> PS: @SuppressWarnings("resource") can be used to suppress inappropriate warnings and Erick Erickson is already looking into warnings related to JavaBinCodec.
>> -----------------------------------------
>>  ant precommit warnings dated to Q2 2017
>> -----------------------------------------
>> 2017-06-21 http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/ReadersAndUpdates.java#L845
>> 2017-06-21 http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java#L186
>> 2017-06-21 http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/index/FrozenBufferedUpdates.java#L144
>> 2017-06-16 http://www.github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/Utils.java#L110
>> 2017-06-16 http://www.github.com/apache/lucene-solr/blob/master/solr/solrj/src/java/org/apache/solr/common/util/CommandOperation.java#L248
>> 2017-06-16 http://www.github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/util/TestUtils.java#L186
>> 2017-05-30 http://www.github.com/apache/lucene-solr/blob/master/solr/core/src/test/org/apache/solr/cloud/autoscaling/TestPolicyCloud.java#L161
>> 2017-05-16 http://www.github.com/apache/lucene-solr/blob/master/lucene/core/src/java/org/apache/lucene/codecs/CodecUtil.java#L523
>> 2017-04-12 http://www.github.com/apache/lucene-solr/blob/master/solr/core/src/java/org/apache/solr/core/CoreContainer.java#L969
>> 2017-04-11 http://www.github.com/apache/lucene-solr/blob/master/solr/solrj/src/test/org/apache/solr/client/solrj/io/stream/StreamExpressionTest.java#L232
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org

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