Opened 5 years ago

Closed 5 years ago

Last modified 4 years ago

#362 closed defect (fixed)

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

Reported by: robert goldman Owned by: mevenson
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.

Subtickets

Attachments (3)

get-java-field.patch (1.8 KB) - added by robert goldman 5 years ago.
Patch for invoke.lisp
fix-set-java-field.patch (2.4 KB) - added by robert goldman 5 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 5 years ago.
Fix what seems to have been a mistake in my last patch.

Download all attachments as: .zip

Change History (12)

Changed 5 years ago by robert goldman

Patch for invoke.lisp

comment:1 Changed 5 years ago by mevenson

  • Milestone set to 1.4.0
  • Owner set to mevenson
  • Status changed from new to accepted
  • Version set to 1.4.0-dev

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

comment:2 Changed 5 years ago by mevenson

Committed as r14715.

comment:3 Changed 5 years ago by mevenson

  • Resolution set to fixed
  • Status changed from accepted to closed

comment:4 Changed 5 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 follow-up: Changed 5 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 5 years ago by robert goldman

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

comment:6 Changed 5 years ago by mevenson

Applied in r14718.

Rock on for the patch!

comment:7 in reply to: ↑ 5 Changed 5 years ago by mevenson

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 5 years ago by mevenson (previous) (diff)

comment:8 Changed 5 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 5 years ago by robert goldman

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

comment:9 Changed 4 years ago by mevenson

  • Milestone changed from 1.4.0 to 1.3.2
Note: See TracTickets for help on using tickets.