bugGNU Octave - Bugs: bug #48866, __java_get/set__

 
 

bug #48866: __java_get/set__

Submitter:  Ernst Reissner <ernstreissner>
Submitted:  Tue 23 Aug 2016 09:33:54 AM UTC
   
 
Category:  None Severity:  3 - Normal
Priority:  5 - Normal Item Group:  None
Status:  Wont Fix Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Tue 23 Aug 2016 04:44:24 PM UTC, comment #8: 

I understand now:
In the long run, you would prefer

object.fieldname and package.classname.fieldname
for _java_get_.
Thus this must be private
in order to avoid that people use them.

Ok.

Ernst Reissner <ernstreissner>
Tue 23 Aug 2016 04:42:42 PM UTC, comment #7: 

Hm,...
you would write code using _java_get_?
Which means that you use private??

Now I understand why you reject my fix. ;-)

Now let us be serious again:
What do you mean by
'The only reason for keeping the wrappers java_get and java_set is for backwards compatibility with the old Java Forge package. '?

Ernst Reissner <ernstreissner>
Tue 23 Aug 2016 04:37:48 PM UTC, comment #6: 

The only reason for keeping the wrappers java_get and java_set is for backwards compatibility with the old Java Forge package. These were originally flagged with a deprecation warning, but that was considered to be too severe because the correct syntax is not supported yet.

If I write some Octave code today that needs to get or set a static attribute of a class or interface, I would use the underscore variants.

Renaming them to not have underscores does not help at all with Matlab compatibility either.

Mike Miller <mtmiller>
Group Member
Tue 23 Aug 2016 03:54:23 PM UTC, comment #5: 

@Mike,
i disagree:
the m-file wrappers do not help at all on our way to matlab compatibility.

What is the advantage?
The disadvantage is complexity and unclarity without gain.

If you prefer wrappers: Would you introduce an m-file wrapper for javaMethod?

Ernst Reissner <ernstreissner>
Tue 23 Aug 2016 02:36:10 PM UTC, comment #4: 

Hi Philip,
yes, I was part of that discussion.
The point was, that there was replacement for member invocatinons of java_get, but not for static ones.
This is still the case.
Thus it is not possible to remove java_get.

A solution would be, to allow java_get for static invocations only,
otherwise write obj.fieldName.

As you point out, there is also javaMethod,
which is analogous: one may write obj.methodName(...)
but for static invocations one has to stick to javaMethod.

Since this is completely analogous,
let us install an analogous solution:
Complete builtin, no m-files.

With constructors, it is similar,
only that there is static form only.


All these three cases can be fixed
as soon as the package.class.method/field/none syntax
can be parsed as classname, field/methodname.
I think my fix is on the way to that solution.

@philip:
my code does not leave anyone in the rain:
not java_get was removed but _java_get_ was renamed into java_get and the m-files for java_get were removed.


Of course, you are right, this is a temporary fix only.
On the other hand: what to do

Ernst Reissner <ernstreissner>
Tue 23 Aug 2016 02:25:28 PM UTC, comment #3: 

I think Philip's comment is correct. The original change was to rename these functions with underscores to keep them private, and the m-file wrappers are there for compatibility until the proper way of getting/setting attributes using "package.class.attribute = value" syntax is implemented.

Mike Miller <mtmiller>
Group Member
Tue 23 Aug 2016 02:17:05 PM UTC, comment #2: 

A while ago (1,5 year ago?) there was a discussion on this as java_get and java_set were deleted as those functions weren't Matlab compatible. In bug #41239 it was decided to reinstate them.

IIRC the core devs rather wanted OO-like syntax. But currently Octave does not support that for static Java stuff, so in the end _java_get_ and _java_set_ were reprieved for 4.2 or until a better Matlab-compatible solution was in place.
Hopefully _java_get_ and _java_set_ will survive 4.2 and maybe even 4.4 :-)

Ernst, I'm in favor of your solution, but it is and remains a temporary fix.

One more thing:
Maybe it is even better to keep _java_set_ / _java_get_ but provide other binary DEFUNs that just call them; much like javaMethod for a while was calling java_invoke() until the latter was finally deprecated (it is still in 4.0.x).
The reason for this suggestion is that there can be quite a bit of code around (not only the io package) that changed to _java_get_ when java_get got deprecated and deleted. Completely removing it would leave that code in the rain.


Philip Nienhuis <philipnienhuis>
Group Member
Tue 23 Aug 2016 01:04:32 PM UTC, comment #1: 

Here is a patch on this.

(file #38327)

Ernst Reissner <ernstreissner>
Tue 23 Aug 2016 09:33:54 AM UTC, original submission:  

Strictly speaking, this is not a bug
but an implementation which is too complicated
and the result of an incomplete change:

Whereas functions javaMethod and javaObject
turned from definitions via m-file,
java_get and java_set are still implemented as m-files.
On the other hand, the core are the builtin functions
_java_get_ and _java_set_.

Removing java_get.m and java_set.m
and renaming _java_get_ and _java_set_ eases implementation
and speeds it up a little bit.


By the way: one has to explicitly remove java_get.m and java_set.m
after make install.
I consider this as a bug in the make process:
The according directory shall be cleaned (retaining only java.opts and javaclasspath.txt).

Ernst Reissner <ernstreissner>

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #38327:  patchBug48866.patch added by ernstreissner (5KiB - text/x-patch)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by mtmiller (Posted a comment)
  • -email is unavailable- added by ernstreissner (Submitted the item)
  • -email is unavailable- added by ernstreissner
  •  

    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
    2016-08-23 mtmiller StatusNone Wont Fix
        Open/ClosedOpen Closed
    2016-08-23 ernstreissner Attached File- Added patchBug48866.patch, #38327
    2016-08-23 ernstreissner Carbon-Copy- Added -email is unavailable-

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code