Make CompositeReader.getSequntialSubReaders() and the corresponding
IndexReaderContext methods return unmodifiable List<R extends IndexReader>
----------------------------------------------------------------------------------------------------------------------------------------------
Key: LUCENE-3866
URL: https://issues.apache.org/jira/browse/LUCENE-3866
Project: Lucene - Java
Issue Type: Improvement
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 4.0
Since Lucene 2.9 we have the method getSequentialSubReader() returning
IndexReader[]. Based on hardly-to-debug errors in user's code, Robert and me
realized that returning an array from a public API is an anti-pattern. If the
array is intended to be modifiable (like byte[] in terms,...), it is fine to
use arrays in public APIs, but not, if the array must be protected from
modification. As IndexReaders are 100% unmodifiable in trunk code (no
deletions,...), the only possibility to corrumpt the reader is by modifying the
array returned by getSequentialSubReaders(). We should prevent this.
The same theoretically applies to FieldCache, too - but the party that is
afraid of performance problems is too big to fight against that :(
For getSequentialSubReaders there is no performance problem at all. The binary
search of reader-ids inside BaseCompositeReader can still be done with the
internal protected array, but public APIs should expose only a unmodifiable
List. The same applies to leaves() and children() in IndexReaderContext. This
change to list would also allow to make CompositeReader and
CompositeReaderContext Iterable<R extends IndexReader>, so some loops would
look nice.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
