Robert Muir created LUCENE-4675:
-----------------------------------
Summary: remove *Ref.copy/append/grow
Key: LUCENE-4675
URL: https://issues.apache.org/jira/browse/LUCENE-4675
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
These methods are dangerous:
In general if we want a StringBuilder type class, then it should own the array,
and it can freely do allocation stuff etc. this is the only way to make it safe.
Otherwise if we want a ByteBuffer type class, then its reference should be
immutable (the byte[]/offset/length should be final), and it should not have
allocation stuff.
BytesRef is none of these, its like a C pointer. Unfortunately lucene puts
these unsafe, dangerous, trappy APIs directly in front of the user.
What happens if i have a bug in my application and it accidentally mucks with
the term bytes returned by TermsEnum or the payloads from DocsAndPositionsEnum?
Will this get merged into a corrupt index?
I think as a start we should remove these copy/append/grow to minimize this
closer to a ref class (e.g. more like java.lang.ref and less like
stringbuilder). Nobody needs this stuff on bytesref, they can already operate
on the bytes directly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
