[
https://issues.apache.org/jira/browse/LUCENE-5372?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-5372:
----------------------------------
Attachment: LUCENE-5372-StringBuffer.patch
Here is a new patch that was created from scratch by using Eclipse search for
java.lang.StringBuffer:
- The queryparser problems are autogen'ed code. I modified the build.xml to do
a replacement in ParseException.java and TokenMgrError.java (queryparser module
and solr-core)
- Some tests called StringWriter.getBuffer().toString() - this was only
detected by forbidden-apis
- Some code parts using regex.Matcher have to use StringBuilder, because
Matcher internally also uses this, so appendReplacement() and appendTail() have
to stay
Because we *have to use StringBuffer* quite often, I did not add it to
forbidden apis, because the exclusions would prevent other forbidden stuff in
the excluded files to be detected.
I will commit this later and close this issue. Since the facet APIs were
cleaned up, the original issue in IntArray disappeared, right? (the class is no
longer there).
> IntArray toString has O(n^2) performance
> ----------------------------------------
>
> Key: LUCENE-5372
> URL: https://issues.apache.org/jira/browse/LUCENE-5372
> Project: Lucene - Core
> Issue Type: Bug
> Components: core/index
> Reporter: Joshua Hartman
> Assignee: Dawid Weiss
> Priority: Minor
> Fix For: 5.0, 4.7
>
> Attachments: 5372-lucene5339.patch, 5372-v2.patch, 5372.patch,
> LUCENE-5372-StringBuffer.patch, LUCENE-5372-forbidden.patch
>
>
> This is pretty minor, but I found a few issues with the toString
> implementations while looking through the facet data structures.
> The most egregious is the use of string concatenation in the IntArray class.
> I have fixed that using StringBuilders. I also noticed that other classes
> were using StringBuffer instead of StringBuilder. According to the javadoc,
> "This class is designed for use as a drop-in replacement for StringBuffer in
> places where the string buffer was being used by a single thread (as is
> generally the case). Where possible, it is recommended that this class be
> used in preference to StringBuffer as it will be faster under most
> implementations."
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
