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

[Robert Goldman]

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.

[Robert Goldman]

Patch for invoke.lisp

[Mark Evenson]

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

[Mark Evenson]

Committed as r14715.

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

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

[Robert Goldman]

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

[Mark Evenson]

Applied in r14718.

Rock on for the patch!

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

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

[Robert Goldman]

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