[jira] [Commented] (LUCENE-10431) AssertionError in BooleanQuery.hashCode()

["Michael Bien (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-10431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17499321#comment-17499321 ] 

Michael Bien commented on LUCENE-10431:
---------------------------------------

IMO: If you don't want client code to use setters: deprecate them. Setters should either work or they shouldn't, it shouldn't depend implementation details like eager hashcode initialization and fail due to a certain query type in the tree.

I would also investigate the following: does the lazy hashcode logic make sense in context of the constructor essentially initializing it eagerly anyway?


The problem for the NetBeans module I am attempting to migrate is though: Some of the queries are not created by netbeans, as you can see in this code (https://github.com/apache/netbeans/blob/04fa8fba812566a211462fc3eef73597fbf3a975/java/maven.indexer/src/org/netbeans/modules/maven/indexer/NexusRepositoryIndexerImpl.java#L1389-L1457 ), they are created by maven-indexer, a third party dependency.

So you could remove the setters but this would slow the lucene 5->8 migration down (for this particular part of NB at least, lucene is used in several places), since someone would have to try to update the API it in maven-indexer first, which would have to happen after its fixed in lucene. NB would be last in the chain.

> AssertionError in BooleanQuery.hashCode()
> -----------------------------------------
>
>                 Key: LUCENE-10431
>                 URL: https://issues.apache.org/jira/browse/LUCENE-10431
>             Project: Lucene - Core
>          Issue Type: Bug
>    Affects Versions: 8.11.1
>            Reporter: Michael Bien
>            Priority: Major
>
> Hello devs,
> the constructor of BooleanQuery can under some circumstances trigger a hash code computation before "clauseSets" is fully filled. Since BooleanClause is using its query field for the hash code too, it can happen that the "wrong" hash code is stored, since adding the clause to the set triggers its hashCode().
> If assertions are enabled the check in BooleanQuery, which recomputes the hash code, will notice it and throw an error.
> exception:
> {code:java}
> java.lang.AssertionError
>     at org.apache.lucene.search.BooleanQuery.hashCode(BooleanQuery.java:614)
>     at java.base/java.util.Objects.hashCode(Objects.java:103)
>     at java.base/java.util.HashMap$Node.hashCode(HashMap.java:298)
>     at java.base/java.util.AbstractMap.hashCode(AbstractMap.java:527)
>     at org.apache.lucene.search.Multiset.hashCode(Multiset.java:119)
>     at java.base/java.util.EnumMap.entryHashCode(EnumMap.java:717)
>     at java.base/java.util.EnumMap.hashCode(EnumMap.java:709)
>     at java.base/java.util.Arrays.hashCode(Arrays.java:4498)
>     at java.base/java.util.Objects.hash(Objects.java:133)
>     at org.apache.lucene.search.BooleanQuery.computeHashCode(BooleanQuery.java:597)
>     at org.apache.lucene.search.BooleanQuery.hashCode(BooleanQuery.java:611)
>     at java.base/java.util.HashMap.hash(HashMap.java:340)
>     at java.base/java.util.HashMap.put(HashMap.java:612)
>     at org.apache.lucene.search.Multiset.add(Multiset.java:82)
>     at org.apache.lucene.search.BooleanQuery.<init>(BooleanQuery.java:154)
>     at org.apache.lucene.search.BooleanQuery.<init>(BooleanQuery.java:42)
>     at org.apache.lucene.search.BooleanQuery$Builder.build(BooleanQuery.java:133)
> {code}
> I noticed this while trying to upgrade the NetBeans maven indexer modules from lucene 5.x to 8.x https://github.com/apache/netbeans/pull/3558



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

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