On Fri, 8 Jan 2021 11:27:57 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> @forax, @plevart could I ask for review once again? > > Hi @stsypanov, > >> The **behavior** of this convenience method is **identical** to that of >> c.addAll(Arrays.asList(elements)) > > What about: > >> The **behaviour** of this convenience method is **similar** to that of >> c.addAll(Arrays.asList(elements)) > > ...since it is not entirely identical. The outcome is usually identical > because collections usually adhere to the specification, but we can not claim > the behaviour is identical if the target collection does not adhere. ...but we could employ this method to guarantee more than `c.addAll(Arrays.asList(elements))` does. So what about: > The behaviour of this convenience method is similar to that of > `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` This means that the method guarantees that the passed in `elements` array will not be modified even if given collection `c` is not trusted. Speaking of that, perhaps you could try benchmarking such `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` and see how it compares. The speed-up you observed from `c.addAll(Arrays.asList(elements))` with some collections was probably a result of them calling .toArray() on the argument collection and incorporating the resulting array into their own data structure in a bulk-copying-way. So `c.addAll(Collections.unmodifiableList(Arrays.asList(elements)))` might have same performance characteristics while guaranteeing same things about argument array. It might be slower when Iterator is employed though because unmodifiableList wrapper wraps Iterator(s) too.... ------------- PR: https://git.openjdk.java.net/jdk/pull/1764
