a few comments on file 39826:

line 45:
+@code{byte}, @code{short}, @code{int}, and @code{long}
without comma before 'and'

line 68:
The special value @code{null} has node associated wrapper class. 
You mean:
The special value @code{null} has no associated wrapper class.
I think the problem occurs when unwrapping not wrapping.
So I would write:
Trying to unbox the special reference @code{null}
results in a NullPointerException because the primitive types
offer no counterpart to @code{null} in java.

line 92
Most of the conversion is straight forward. 
More subtile are the integer types

This does not fit.
I would write:
Most of the conversion is straight forward. 
Care has to be taken with conversion of octave unsigned integer types since they can exceed the range of Java's according signed integer types...

line 95:
'as a consequence' does not fit.
I just would write: 'Thus'

line 96:
singed-->signed.

line 116:
another two exceptions are the @code{void} and @code{null}.
should be
another two exceptions are the return type @code{void} and the return value @code{null}.

The rest seems ok.
Note that this is not the full truth!

by the way,
this is the place where to include the patch for bug 9085:
besides methods and fieldnames
also constructors shall be accessible.

@Ernst: Sorry for the delay, we had a new bug fixing release, including your documentation right now:

https://www.gnu.org/software/octave/doc/interpreter/How-to-use-Java-from-within-Octave.html#How-to-use-Java-from-within-Octave

Dear Ernst,

I think in the mailing list, we should stay with one thread one to organize which item to attack next. Thus keeping the noise low there and the discussions about specific items here at Savannah.

Alright, a first discussion I want to do about Patch C file #38267. Basically it only renames functions. Is the term (un-)boxing so confusing? I know it is something very Java-related.

My votes against doing this is, that it is only "internal" no user working with the interface will ever see these function names.

The remaining two patches are in progress right now.

Well, had to add further information:
types void, null-value, char-types.

Still a lot of material is missing:
- for numeric types and for char types
  manual conversions shall be mentioned: double(.) and others.
- Alternative conversions of return values
- preferences in conversions of argument types
  and why the matlab rules are not well defined.
...


(file #38263)

The subject of conversion of Octave types to Java types
e.g. when invoking Java methods
and back conversion, e.g. of the return values
is a complex subject.
Also Matlab documentation expands a lot on that.

I feel,
an according section in Octave's manual is strongly required.