Question

Sometimes I seem to be quite inefficient. When I was nearly finished typing this, I managed to find the appropriate bug report at Sun. I then thought well, might as well post it, having the screenshot and all. Answer follows.

I know, “SELECT isn’t broken”, and it’s always my fault. But here, I really don’t get why it should be. My code snippet:

List<IGraphEdge> rgSrc = this._rgGetPath();
List<IGraphEdge> rgDst = new ArrayList<IGraphEdge>(rgSrc.size());
Collections.copy(rgDst, rgSrc);

This throws an IndexOutOfBoundException with the message

java.lang.IndexOutOfBoundsException: Source does not fit in dest
        at java.util.Collections.copy(Collections.java:548)

In the debugger, when I step into Collections.copy, the two ArrayList instances look like this:

Debugger view http://static.theuprightape.net/ql/img/debugger.png

So, there’s the capacity in dest to hold that one element from src, although, naturally, the size of dest is still 0, after all, this is what I want to change by calling copy().

Looking at the source code of the OpenJDK implementation, it’s clear why the error is thrown:

public static <T> void copy(List<? super T> dest, List<? extends T> src) {
    int srcSize = src.size();
    if (srcSize > dest.size())
        throw new IndexOutOfBoundsException("Source does not fit in dest");

So please tell me, is that a bug, or what am I doing wrong?

Answer 1

It’s not looking at the capacity, it’s looking at the size. That is, the destination should contain elements, which are to be overwritten by the source list.

I’ve never run into a case where this would be useful. Usually what you want is a copy constructor in one of the List implementations, or the addAll method of the Collection interface.