[
https://issues.apache.org/jira/browse/LUCENE-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12759572#action_12759572
]
Uwe Schindler commented on LUCENE-1926:
---------------------------------------
I think this info from next(Token) javadocs also applies to incrementToken():
{code}
* Also, the producer must make no assumptions about a {...@link Token} after
it
* has been returned: the caller may arbitrarily change it. If the producer
* needs to hold onto the {...@link Token} for subsequent calls, it must
clone()
* it before storing it. Note that a {...@link TokenFilter} is considered a
* consumer.
{code}
> Back compat break with old next() consumer API
> ----------------------------------------------
>
> Key: LUCENE-1926
> URL: https://issues.apache.org/jira/browse/LUCENE-1926
> Project: Lucene - Java
> Issue Type: Bug
> Components: Analysis
> Affects Versions: 2.9
> Reporter: Robert Muir
> Attachments: CaptureStateTestcase.java
>
>
> There is a bug that causes tokenstreams to return different results,
> depending upon whether they are consumed with the incrementToken() api or the
> next() api.
> I found this because the Solr analysis tool in the admin page uses the next()
> api, and i was seeing strange results.
> I've created a test case to show the problem. when calling captureState(),
> the current state is erased, but only when consuming with the next() api.
> If I consume with incrementToken(), things work.
> {code}
> State tempState = captureState(); // after we capture state here, things get
> strange.
> String right = termAtt.term(); // when using old consumer API, this value is
> wrong!!!!
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
