oh ok. I missed the 'static class fields' detail.

I believe java dot notation has been around for a little while now.  java_get and java_set are still around in 5.2.0, and I don't see them on legacy or deprecated lists.

> Then can we please "un"deprecate jave_get and java_set now?

Sure.  Go ahead and make that change.

> > After dot notation is available it would be wise to bring this
> > issue back to the Octave Maintainers list to see if we want to
> > diverge from the Matlab Java interface or not. It would be a
> > superset of Matlab, but it still might create problems if
> > people code to the Octave interface, say while working at home,
> > and then bring it to work to simulate on Matlab.

> This already happens and is not a problem. We have rows, columns, ishandle,
> iscolormap, prepad, postpad, etc... We have ! for negation, and # for
> comments. Octave users know there's functionality in Octave that is still
> missing in Matlab.

Yes, but I still think it is worth having a short discussion before we introduce each new incompatibility.

All sensible reasons.  I'm not opposed to keeping around some version of javaGet/javaSet until there is a guaranteed working replacement.

After dot notation is available it would be wise to bring this issue back to the Octave Maintainers list to see if we want to diverge from the Matlab Java interface or not.  It would be a superset of Matlab, but it still might create problems if people code to the Octave interface, say while working at home, and then bring it to work to simulate on Matlab.

The dot notation should be available for 4.2 release which is just when the _java_get_ internal function will be retired.

Desperate? Nah, not quite.

But it would be more practical for me if it worked. I usually work with bleeding edge Octave versions incl. a set of favorite OF packages; I'm prepared for trouble so this bug is just an annoyance.

I didn't know about _java_get_, that'll may come in handy, thank you for the hint.
java_get() used to be a C++ file as well in the OF java package:

octave:1> which java_get
'java_get' is a function from the file X:\Octave\Octave3.6.4_gcc4.6.2\lib\octave\packages\
java-1.2.9\i686-pc-mingw32-api-v48+\__java__.oct

(So did you just rename java_get to _java_get_ in the .cc source file?)

Tried your suggestion, but alas: it is not going to work, unless with undue kludges.

In Octave-4.1.0+

>> cl = javaObject ('org.apache.poi.ss.usermodel.Cell')
error: [java] java.lang.NoSuchMethodException: org.apache.poi.ss.usermodel.Cell

...mayby happening because Cell is an interface rather than a class. The derived classes (that do have constructors) are protected, thus inaccessible.
In Matlab it doesn't work either:

>> cl = javaObject ('org.apache.poi.ss.usermodel.Cell')
Error using javaObject
No constructor with appropriate signature exists
in Java class org.apache.poi.ss.usermodel.Cell

Creating a Cell won't work that easily, because:
- to be able to create a Cell a Row is needed;
- to be able to create a Row, a Worksheet is needed;
- to be able to create a Worksheet, a Workbook (spreadsheet) is needed.
Once that one scheme works (can be done), the static field values can only be accessed one by one each for a new Cell, as each Cell is typed. So that'll clobber up new worksheets.

In conclusion I rather wait with adapting the io package scripts until a better solution is available.

Perhaps java_get() (and for that matter, java_set()) have been deprecated a bit overly fast w/o having a working replacement in place. For the other deprecated functions (java_invoke and java_new) replacement functions were already there.
At the time we didn't anticipate that we'd have another stable release pending (= 4.0) while we're already busy with 4.1+

FTR, indeed on Matlab r2012a the dot notation works:

>> org.apache.poi.ss.usermodel.Cell.CELL_TYPE_BOOLEAN

ans =

     4

>>

There are two parts to this.  Eventually we will have Matlab compatibility.  See http://www.mathworks.com/help/matlab/matlab_external/creating-and-using-java-objects.html, and in particular the section "Accessing Data from a Static Field" for the way things will work.

For reading a static class value Matlab supports standard dot notation such as

int_type = java.lang.Integer.TYPE

This sort of dot notation should be possible when classdef support is available, but that is a ways off (4.2 release).

Note that in Matlab reading a class value is possible using the notation above, but writing to a class value always requires creating an instance of the class first and then assigning to that instance.

In Octave, reading and writing of static class values is already supported with this two step approach.  An example of reading the TYPE field is

jint = javaObject ("java.lang.Integer", 1);
int_type = jint.TYPE;
int_type.toString
ans = int

Changing your example over to the supported syntax

obj = javaObject ("org.apache.poi.ss.usermodel.Cell");
ctype(1) = obj.CELL_TYPE_NUMERIC;

And it may not even require the instantiation of the object "obj" because you may already have an instance of the class in the previous code.

This style of code for reading is perfectly acceptable Matlab syntax so it will not go away even when 4.2 is released.  If you want to change over code to use the two-step read sequence you can then have your choice to update it to dot notation in 4.2 or just leave it as is because it works.