Occasionally in Java, you come across an API that makes you sit up and go "What were they thinking?" Take, for example, the code to list all the threads in the current ThreadGroup. Rather than having the obvious method: i.e. one that returns a list (or array) of threads, the signature looks like this:

int enumerate(Thread[] list)

You pass an empty array to the method, which will be filled with Thread objects. The method then returns the number of threads it placed in the array. If the array is not long enough to accept all the threads, the overflow will be silently discarded.

To initialise the array, you must rely on ThreadGroup#activeCount, which only returns an approximation of the number of threads that enumerate might return.

If you're looking to avoid memory leaks in a non-garbage-collected environment, then it makes perfect sense for an API to push responsibility for memory management back up its caller, and to gracefully handle whichever buffer-size it's given to fill. When you've got pervasive GC, it just looks (and is) clumsy.

So the obvious answer to "What were they thinking?", of course, is "They were thinking like C programmers".

Which in turn leads one to suspect that this particular API has been around since before Java was called Java.