>> Then can we please "un"deprecate jave_get and java_set now?
>
> Sure. Go ahead and make that change.
Done in stable branch as mentioned on mailing list. See http://hg.savannah.gnu.org/hgweb/octave/rev/54ab08d8de55

> 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.

Rik said:
> All sensible reasons. I'm not opposed to keeping around some
> version of javaGet/javaSet until there is a guaranteed working
> replacement.
Then can we please "un"deprecate jave_get and java_set now? Because some working does not exist yet. What will I do if I release a package 2 months before 4.2?
> 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.

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.

Can we rethink removal of this functions?
1. Alternative functions are meant to exist in 4.2 but deprecating them now means that in version 3.8 and 4.0, there is no alternative to a user (the user that writes code for others, not the end user). Yes, we can use __java_get__ but that is not any different that using 'warning off; __java_get__ (); warning on;`. The whole point of deprecating functions, is to give users time to adapt their code. This does not give them anytime. When the dot notation will be available, is when this functions disappear.
2. Having a function for this things is handy. Should we really only support dot notation? Why can't we have functions too? We have to create array, objects, and to call methods. Why not to access and set field values? If so, I guess that javaSet and javaGet may fit better next to JavaArray, javaMethod, and javaObject.
3. Finally, the idea is that in 4.2 this notation will appear because classdef will exist. But will it really? classdef is still in development but is it really part of the plan to also make this notation work in 4.2? Even if it is planned, it's doesn't sound safe to start the removal of these when we don't really have the replacement working yet.

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

I just hit the same issue.
will the private __java_get__ be removed at the same time as java_get()? Because at the time there is no other function capable of doing it when there is no constructor available.

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:
(So did you just rename java_get to _java_get_ in the .cc source file?)

So, it probably is better to wait for the dot notation to become available as part of the classdef code.
If you're desparate to have spreadsheet support on the dev branch you can always use the hidden internal function _java_get_. It behaves just like the deprecated java_get and is in C++, rather than an mfile.

Tried your suggestion, but alas: it is not going to work, unless with undue kludges.
In Octave4.1.0+
...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:
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:

Thanks for the hints.
I know about the desired dot notation and the (obvious) limitations of setting class values.
The twostep approach may well be the "stable" workaround. But I have to check first as in practice the Cell interface might only be used, or be accessible, later on in the code.
Perhaps it would even be better if Java could be dropped completely for spreadsheet I/O; there's also C++ code around, but much more messy.
From a developer's POV however, using prebaked Java classes and methods simply saves an enormous amount of time & effort.

There are two parts to this. Eventually we will have Matlab compatibility. See http://www.mathworks.com/help/matlab/matlab_external/creatingandusingjavaobjects.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
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
Changing your example over to the supported syntax
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 twostep 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.

In Octave4.1.0+ java_get(), java_set() and some other functions have been removed cf. the deprecation schedule; however there is no replacement in place yet for getting static field values of Java classes.
See also https://savannah.gnu.org/task/?12601
A while ago this was already brought up in the mailing list or in the bug tracker, but I couldn't find it.
Slight annoyance is that this deprecation will render half of the Javabased spreadsheet I/O in the io package nonfunctional until this has been fixed. Example, code like:
is vital for some functions but is broken in 4.1.0+. Same goes for code to check for version number of certain Java class libs.
I assume that we'll first wait until 4.0 is released before this issue will get attention, right? (after all 4.1.0+ is quite bleeding edge)
If so, status can be set to "postponed"
