Vinoth Kumar Kannan wrote:Why is that an exception is thrown when the subList is referred, after the backingList being modified in the subList area of it?
It's not clear whether your question is about the design decision (in which case I don't know / don't really care) or the mechanism that throws the exception.
If the latter, look at the code for SubList in AbstractList.java. The current number of modifications of the backing list is cached in the field
expectedModCount when the SubList is constructed, and incremented whenever a modification is made via the SubList. Then, when any operation is performed on the SubList, the actual modification count of the backing list is compared to this cached value, and if they differ a ConcurrentModificationException is thrown.
About the design decision, I could hazard a guess that it was considered too expensive to cache all details of every modification and compute whether any interim modification of the backing list would actually make the SubList invalid, so a short cut was adopted that didn't allow
any modifications to the backing list post-creation of the SubList. But as already said, I don't really know nor do I worry my head about that. It's adequate that the API documentation reflects the facts unequivocally.