Re: bug in invoke + reflection patch/improvement

[Per Bothner <per at bothner dot com>]

Martin Atzmueller <martin.atzmueller@gmx.net> writes:

> Consider the following case:
> When working interactively, Kawa does use reflection to access methods.
> 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.

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.

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.

> I've implemented a 'ReflectionHelper' class, that allows interactive
> (using
> the listener) access to non-public objects.
> This is appended at the bottom, together with all the patches to the
> kawa-reflection-classes that were needed to make this work.
> 
> What do you think about this?

I have mixed feelings.  Something like this may make sense.

> Will this be included in the next release?

I'll be vacationing for a few weeks soon.  We'll see when I get back.

> I think it's a really neat feature, especially when debugging code.

Examples of use when debugging?

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.

I appreciate the contribution.  If I seem a little negative, it is
partly because I have too mny loose ends to try to deal with in the
next couple of days ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/~per/