This is the mail archive of the
java-discuss@sourceware.cygnus.com
mailing list for the Java project.
Re: question about reflection
- To: per at bothner dot com (Per Bothner)
- Subject: Re: question about reflection
- From: Godmar Back <gback at cs dot utah dot edu>
- Date: Wed, 24 Nov 1999 18:36:58 -0700 (MST)
- Cc: java-discuss at sourceware dot cygnus dot com
>
> Godmar Back <gback@cs.utah.edu> writes:
>
> > From looking at class.c:make_class_data, it appears that private methods
> > are omitted from the method table if inlining or optimization is
> > turned on.
> >
> > As a result, they won't be available for reflection in such
> > functions as Class.getDeclaredMethod(s).
> >
> > Is this intended?
>
> There should probably be some flag to control this. But, yes, it seems
> reasonable to me that private methods may disappear if inlining or
> optimization is turned on. After all, we may not have a non-inlined
> version of the method, and there seems to be little reason to generate one.
>
I think having a flag "emit accurate meta-data" would be very nice indeed.
After all, I'm constructing kaffe's meta data structures from what gcj
puts in the object file, and it doesn't really help if private native
methods have disappeared when I need to invoke them. ;-)
> Yes, valid programs can notice the difference through reflection,
> so strictly speaking we violate the "as-if rule". But I can't think
> of any real need for keeping the methods around, except debugging or
> introspection, in which case optimization may break a number of things.
>
Agreed.
Nevertheless, I think that supporting basic levels of optimization and
accurate reflection at the same time should be possible and is desirable,
especially considering that the granularity at which the optimization level
is chosen is a complete class. In other words, it would be bad if I had
to forego basic code optimizations in most methods just to guarantee that
reflection for a few methods will work.
- Godmar