[
https://issues.apache.org/jira/browse/LUCENE-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16247638#comment-16247638
]
Robert Muir commented on LUCENE-8047:
-------------------------------------
These token type instances are intentionally using == with "type" and it is not
a bug, it is totally safe, because they are comparing against the exact static
final constants they are looking for. Some of these comparisons (e.g.
CJKBigram) happen per-character and the others happen per-word. i don't think
they should be changed to equals because it will only make worse performance.
The SUFFIX_CONDITION_REGEX_PATTERN doesn't need equals, it is a private mathod
used only internally, and is only passed either SUFFIX_CONDITION_REGEX_PATTERN
or PREFIX_CONDITION_REGEX_PATTERN. so it wants to know, am i processing
suffixes or prefixes. there is not a third possibility.
> Comparison of String objects using == or !=
> -------------------------------------------
>
> Key: LUCENE-8047
> URL: https://issues.apache.org/jira/browse/LUCENE-8047
> Project: Lucene - Core
> Issue Type: Improvement
> Components: modules/analysis
> Affects Versions: 7.0.1
> Environment: Ubuntu 14.04.5 LTS
> Reporter: song
> Priority: Minor
> Labels: performance
>
> My tool has scanned the whole codebase of Lucene and found there are eight
> practice issues of string comparison, in which strings are compared by using
> ==/!= instead of equals( ).
> analysis/common/src/java/org/apache/lucene/analysis/hunspell/Dictionary.java
> {code:java}
> conditionPattern == SUFFIX_CONDITION_REGEX_PATTERN
> {code}
> analysis/common/src/java/org/apache/lucene/analysis/cjk/CJKBigramFilter.java
> {code:java}
> if (type == doHan || type == doHiragana || type == doKatakana || type ==
> doHangul) {
> {code}
> analysis/common/src/java/org/apache/lucene/analysis/standard/ClassicFilter.java
> {code:java}
> if (type == APOSTROPHE_TYPE &&...){
> } else if (type == ACRONYM_TYPE) {
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
