Hi Mike,
what kind of information do you need to confirm or reject this bugreport?

Hi Mike,
I overread a comment of you:
'To be compatible, the size of a Java array should always be Nx1 reflecting the length of the outermost array. The number of dimensions (ndims) should always be 2. It would be nice to confirm whether numel agrees with size for 2 or higher-dimensional Java arrays.'

Hm, according to matlab docs
http://de.mathworks.com/help/matlab/ref/numel.html,
n = numel(A) is equivalent to prod(size(A)).
So size(.) determines numel(.) not the other way round.
In the docs, nothing is mentioned on java or not.
This is not necessary,
because size makes the distinction.
That's the way, also Octave shall implement numel.

So, I think there is no futher info required
and I would vote (if i could) for confirming the bug.

Hi Mike,
so you can change the status from need info to confirmed?
I would fix easily.

In

http://de.mathworks.com/help/matlab/ref/size.html

we read:

For a Java array, size returns the length of the Java array as the number of rows. The number of columns is always 1. For a Java array of arrays, the result describes only the top level array.

In fact, in octave,

octave:22> arr=javaArray('java.lang.Object',5)
arr =

<Java object: java.lang.Object[]>

octave:23> size(arr)
ans =

   5   1

Which is correct: 5 is the number of rows and 1 the number of columns.

But lets go on:

octave:24> arr=javaArray('java.lang.Object',5,4)
arr =

<Java object: java.lang.Object[][]>
octave:25> size(arr)
ans =

   5   4

which is not correct.

The result should still be 5 1.