On Fri, 8 Jan 2021 11:39:17 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> 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.... @plevart done. Should I also rename this PR to e.g. 'Fix performance-related notation in Collections.addAll'? ------------- PR: https://git.openjdk.java.net/jdk/pull/1764
