On Thu, 14 Jan 2021 10:18:23 GMT, Peter Levart <plev...@openjdk.org> wrote:
>> ...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'? > > I think the title of JIRA ticket has to be the same as that of PR (with JIRA > bug number prepended) in order to pass all checks needed for integrating. So > If you modify both, it would be fine. I cannot modify JIRA ticket without account there, so let's keep it as is ------------- PR: https://git.openjdk.java.net/jdk/pull/1764
