[ https://issues.apache.org/jira/browse/LUCENE-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Uwe Schindler updated LUCENE-3866: ---------------------------------- Summary: Make CompositeReader.getSequentialSubReaders() and the corresponding IndexReaderContext methods return unmodifiable List<R extends IndexReader> (was: Make CompositeReader.getSequntialSubReaders() and the corresponding IndexReaderContext methods return unmodifiable List<R extends IndexReader>) > Make CompositeReader.getSequentialSubReaders() 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: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org