Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#362 closed defect (fixed)

GET-JAVA-FIELD doesn't behave orthogonally when TRY-HARDER is T

Reported by: Robert Goldman Owned by: Mark Evenson
Priority: major Milestone: 1.3.2
Component: JSS Version: 1.4.0-dev
Keywords: Cc:
Parent Tickets:

Description

GET-JAVA-FIELD, when its optional TRY-HARDER argument is NIL, will return any public field on its argument object, whether defined locally or inherited.

When TRY-HARDER argument is true, on the other hand, it will return non-public fields as well as public ones but only non-public fields that are defined locally -- not non-public fields that are inherited.

This non-orthogonality seems wrong (just read the contorted description above and imagine it as a docstring!). I am attaching a proposed patch which searches up the class hierarchy to find inherited non-public fields when TRY-HARDER is true.

Attachments (3)

get-java-field.patch (1.8 KB) - added by Robert Goldman 10 years ago.
Patch for invoke.lisp
fix-set-java-field.patch (2.4 KB) - added by Robert Goldman 10 years ago.
Patch for invoke.lisp that extends the fix for GET-JAVA-FIELD to SET-JAVA-FIELD
new-jfield-patch.patch (1.6 KB) - added by Robert Goldman 10 years ago.
Fix what seems to have been a mistake in my last patch.

Download all attachments as: .zip

Change History (12)

Changed 10 years ago by Robert Goldman

Attachment: get-java-field.patch added

Patch for invoke.lisp

comment:1 Changed 10 years ago by Mark Evenson

Milestone: 1.4.0
Owner: set to Mark Evenson
Status: newaccepted
Version: 1.4.0-dev

I'll have a look: thanks for the patch!

comment:2 Changed 10 years ago by Mark Evenson

Committed as r14715.

comment:3 Changed 10 years ago by Mark Evenson

Resolution: fixed
Status: acceptedclosed

comment:4 Changed 10 years ago by Robert Goldman

Quick question: should we modify set-java-field orthogonally?

I haven't ever tried to set a field, so that's why I didn't notice this....

comment:5 Changed 10 years ago by Robert Goldman

Here's a patch for this. I also added a condition for not finding the field. I'm not sure that's the right thing, though, so perhaps a simple ERROR as in the current code would be better. Here's why: if we fail to find the field in the JSS code, when try-harder is non-NIL you get a special condition. But if try-harder is nil, you fall through to the JFFI code, where you don't get this condition.

In general, this is probably an artifact of the split between JSS and JFFI, which seems undesirable. It would be nice to simply fuse JSS into JFFI so that there's only one JFFI to keep track of....

Changed 10 years ago by Robert Goldman

Attachment: fix-set-java-field.patch added

Patch for invoke.lisp that extends the fix for GET-JAVA-FIELD to SET-JAVA-FIELD

comment:6 Changed 10 years ago by Mark Evenson

Applied in r14718.

Rock on for the patch!

comment:7 in reply to:  5 Changed 10 years ago by Mark Evenson

Replying to robert goldman:

In general, this is probably an artifact of the split between JSS and JFFI, which seems undesirable. It would be nice to simply fuse JSS into JFFI so that there's only one JFFI to keep track of....

We desire to have a single JFI, that which is contained in the JAVA package, and many extensions (JSS, JFLI, Clojure, etc.) for experimentation. Currently the difference between JAVA and JSS is simply: the JAVA interfaces attempt to obey the JVM's notion of what is allowed access to other classes. The JSS interface is decidedly hostile to any notion of security: we try everything until we find a strategy that works.

Last edited 10 years ago by Mark Evenson (previous) (diff)

comment:8 Changed 10 years ago by Robert Goldman

I think I must somehow have messed up the patch file I sent you. The report function definition is wrong now -- it has the invocation rather than the actual report function. Please see the patch file I will attach in a moment.

Changed 10 years ago by Robert Goldman

Attachment: new-jfield-patch.patch added

Fix what seems to have been a mistake in my last patch.

comment:9 Changed 9 years ago by Mark Evenson

Milestone: 1.4.01.3.2
Note: See TracTickets for help on using tickets.