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

 
 

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

Submitted by:  Philip Nienhuis <philipnienhuis>
Submitted on:  Wed 15 Jan 2014 05:20:55 PM UTC  
 
Category: LibrariesSeverity: 3 - Normal
Priority: 5 - NormalItem Group: Matlab Compatibility
Status: PostponedAssigned to: None
Originator Name: Philip NienhuisOpen/Closed: Open
Release: devOperating System: Any

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

(Jump to the original submission Jump to the original submission)

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

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

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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+

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

Philip Nienhuis <philipnienhuis>
Project 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>
Project 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

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

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

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by rik5 (Posted a comment)
  • -unavailable- added by philipnienhuis (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed 15 Jan 2014 07:18:41 PM UTCrik5Item 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.1-cleanup1