RFR 8014824: Document Spliterator characteristics and binding policy of java util collection impls
chris.hegarty at oracle.com
Thu Aug 8 09:59:18 UTC 2013
On 08/08/2013 10:00 AM, Paul Sandoz wrote:
> The following patch updates documentation for various spliterators:
> Mostly this is just clarifying stuff that was missing, but there are a few cases of a spec change to Collections (CCC will be created):
> This is for the Collection.empty/singleton/nCopies relaxing the reporting of characteristics for spliterators containing 0 or 1 elements. It's more efficient to share code for empty and singleton spliterator implementations (and instance for the former) rather than attempting to conform the required characteristics of the collection, which will anyway have little or no benefit in terms of the client trying to optimize based on those characteristics.
I understand the reason for these spec clarifications, but it just
doesn't feel right, to me, that we return Collections that do not obey
their own specification, even if we explicitly spell it out.
What is to stop others from doing the same? In which case a user can
never depend on the specified characteristics being returned.
P.S. sorry if this has already been discussed, and agreed upon, elsewhere.
More information about the core-libs-dev