Re: bug in invoke + reflection patch/improvement

[Martin Atzmueller <martin dot atzmueller at gmx dot net>]

> > Say we have a non-accessible Super-Class P, implementing a public
> method
> > m,
> > and a SubClass C.
> > When trying to use Method m of P, JDK1.1 will not allow
> > it _using_ reflection. So Kawa, in the current version, will neither
> allow it.
> > This does work in compiled Java Code, though.
To be more explicit: it works in compiled _JAVA_ code. It seems to work in
compiled KAWA code, too (using kawa -C ...).
It happened not to work in the scheme-listener. Hence the patch.

> Well, I do think compiled and interpreted code should act the same.
> However, reflection is rather peculiar when it comes to fields/methods
> that are neither public nor private, cine wha is permitted depends on
> the *static* context.  Thus "apply" can't really mimic that.
I'm not sure, if I understand you correctly. Of course it depends on the
static context. But in the example I gave, it really should not matter.

> This may indicate that we need to distinguish
> invoke-using-compiled-methodcall
> >from invoke-using-reflection.  They have the same name and api, and
> most of the time the do the same thing, but they are subtrly different.
Could you elaborate a bit on this, please? If I understand the code
correctly, invoke just tries its "apply" method. Couldn't it be possible to
compile the code first then evaluate (I thought this was the way to go in Kawa,
but it seems I'm wrong ...). But then we'd have the the same behavior.



> > I think it's a really neat feature, especially when debugging code.
> 
> Examples of use when debugging?
Well, that's easy: you can just start a listener, get an instance of a
java-class, and play with it in the listener. And you have access to all
fields, so you can do on-the-fly inspection. I think it's much easier to try out
classes interactively, instead of writing a clumsy main-method each time.

> If I get full continuation support written, it will then be practical
> to write a debugger in "pure Java" (since activation frames will be
> objects).
> We will probably need reflection support.
Yeah, this would be really great. A debugger like in common-lisp would be
really helpful, sometimes.


Martin Atzmueller

-- 
Homepage: http://www.atzmueller.net/
Email: martin@atzmueller.net

Sent through GMX FreeMail - http://www.gmx.net