bugGNU Octave - Bugs: bug #41239, Dot notation for accessing Java...

 
 

bug #41239: Dot notation for accessing Java static class fields

Submitter:  Philip Nienhuis <philipnienhuis>
Submitted:  Wed 15 Jan 2014 05:20:55 PM UTC
   
 
Category:  Libraries Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Matlab Compatibility
Status:  Postponed Assigned to:  None
Originator Name:  Philip Nienhuis Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 11 Mar 2020 05:31:32 PM UTC, comment #15: 

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

Nicholas Jankowski <nrjank>
Group Member
Wed 11 Mar 2020 05:13:59 PM UTC, comment #14: 

Java dot notation is still a missing feature for Octave.  For compatibility, it should be implemented.

Rik <rik5>
Group administrator
Wed 11 Mar 2020 05:04:22 PM UTC, comment #13: 

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.

Nicholas Jankowski <nrjank>
Group Member
Sat 12 Jul 2014 10:26:22 PM UTC, comment #12: 


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

Carnë Draug <carandraug>
Group Member
Thu 10 Jul 2014 03:13:15 PM UTC, comment #11: 


> 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 <rik5>
Group administrator
Thu 10 Jul 2014 11:42:58 AM UTC, comment #10: 

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.

Carnë Draug <carandraug>
Group Member
Wed 09 Jul 2014 08:30:57 PM UTC, comment #9: 

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.

Rik <rik5>
Group administrator
Wed 09 Jul 2014 05:09:15 PM UTC, comment #8: 

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.

Carnë Draug <carandraug>
Group Member
Tue 08 Jul 2014 03:44:14 AM UTC, comment #7: 

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

Rik <rik5>
Group administrator
Mon 07 Jul 2014 11:21:25 PM UTC, comment #6: 

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.

Carnë Draug <carandraug>
Group Member
Thu 16 Jan 2014 06:00:52 PM UTC, comment #5: 

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?)

Philip Nienhuis <philipnienhuis>
Group Member
Thu 16 Jan 2014 04:31:21 PM UTC, comment #4: 

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

Rik <rik5>
Group administrator
Thu 16 Jan 2014 04:07:23 PM UTC, comment #3: 

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

>>


Philip Nienhuis <philipnienhuis>
Group Member
Wed 15 Jan 2014 09:33:50 PM UTC, comment #2: 

Thanks for the hints.

I know about the desired dot notation and the (obvious) limitations of setting class values.

The two-step 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 pre-baked Java classes and methods simply saves an enormous amount of time & effort.

Philip Nienhuis <philipnienhuis>
Group Member
Wed 15 Jan 2014 07:18:41 PM UTC, comment #1: 

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.

Rik <rik5>
Group administrator
Wed 15 Jan 2014 05:20:55 PM UTC, original submission:  

In Octave-4.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 Java-based spreadsheet I/O in the io package non-functional until this has been fixed. Example, code like:

ctype(1) = java_get ("org.apache.poi.ss.usermodel.Cell", "CELL_TYPE_NUMERIC");


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"

Philip Nienhuis <philipnienhuis>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by apjanke (Adding myself)
  • -email is unavailable- added by nrjank (Posted a comment)
  • -email is unavailable- added by rik5 (Posted a comment)
  • -email is unavailable- added by philipnienhuis (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2020-07-08 apjanke Carbon-Copy- Added -email is unavailable-
    2014-01-15 rik5 Item GroupRegression Matlab Compatibility
        StatusNone Postponed
        Summaryjava_get/-set removed in dev (4.1.0+) w/o replacement for static fields Dot notation for accessing Java static class fields

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code