[armedbear-devel] Proposed patch for ticket #58 (inspection of Java objects)

[Alessio Stalla]

On Tue, Jul 28, 2009 at 10:58 PM, Tobias C. Rittweiler<tcr at freebits.de> wrote:
> Alessio Stalla writes:
>
>> I have added to our inspector the ability to look into Java classes,
>> showing the values of fields and allowing them to be further
>> inspected.
>
> Cool!
>
>
>> NB: since the field values are read when the object is first
>> inspected, and then translated to Lisp objects,
>
> Is the translation cached?

Yes, but not by my code. The abcl inspector expects the objects it's
showing are the actual objects, not representations of them, so it has
no concept of "refreshing" an object.

>
>> the inspector will NOT reflect the current state of the object should
>> it be altered (e.g. by another thread, or interactively by the user
>> while inspecting). This is important especially wrt. inner objects: if
>> A contains B and later C, inspecting A at a certain time will show me
>> B, and inspecting B will, unsurprisingly, show me B, not C - even if A
>> contains C now. I don't know if our inspector behaves like this for
>> other objects too or not, but I don't see any (easy) way to change
>> this fact.
>
> If the translation is not cached, reinspection of A results in correctly
> showing C, right?
>
> At least in the Slime Inspector, objects are reinspected on navigating
> back from an inner object. I.e. in your example above: you'd start with
> A, would go down to B, and when going back to A, A is reinspected and
> hence will now show C instead of B.

Sure, I think the abcl inspector does this too. However, with Lisp
objects B is B itself; with Java objects, B is a representation of
object B' in a certain state. If B' changes, B remains the same.

Example: A contains a field which is an array B of 10 ints, all zeros.
When I inspect B, I'll see a Lisp array of 10 Fixnums, all zeros. I
can inspect one of them, and see it's zero; then I change B to contain
all 42s, and return to the previous inspected object: I'll still see a
Lisp array of 10 zeroed Fixnums. If I reinspect A, I'll see of course
the new state. This is because the Java array has been translated to
Lisp, and the Lisp object has been inspected instead. Also if I modify
the inspected array, the original one won't get modified.

However, I understand now that I can change that easily - I can return
the raw untranslated Java object - you'll see all fields have a value
of #<JAVA-OBJECT foo.bar.Class>, even for numbers, arrays, strings and
other simple types; but that will always reflect the current object,
and you'll still be able to inspect it to see what it is, so I think
it's a sensible thing to do.

Bye,
Alessio