PR libgcj/25265 second part: Throw NoSuchFieldError for missing fields

[Andrew Haley]

Bryce McKinlay writes:
 > Andrew Haley wrote:
 > > This is the second part of the patch, the part that defers throwing a
 > > NoSuchFieldError until we try to use a missing field.
 > >
 > > Unfortunately, this really requires us to insert some
 > > compiler-generated code.  On the plus side, this is only necessary
 > > when accessing fields that beling to some other class, and in
 > > Object-Oriented programming we really aren't supposed to do that sort
 > > of thing.  So it doesn't matter.  ;-)
 > >   
 > 
 > Accessing fields across public class boundaries frowned upon, but I 
 > don't think it is unusual in some other cases. eg: It seems reasonably 
 > common to access fields directly when:
 > 
 > - the field accesses are between nested classes
 > - the fields are in a superclass
 > 
 > Classpath, for example, has many examples of the first type in 
 > particular.

That's a really good point!  Maybe with a bit of thought the runtime
test could be removed for that first case, because the inner class
will be compiled and resolved with its enclosing class, so accesses to
outer fields should always be OK.  That's perhaps worth doing.

WRT the second, I don't see how accessing fields in a superclass is
any more virtuous than accessing a field in any other class, but hey
-- we have to run the Java programs that people write, not the ones
that we would like them to write.  :-(

 > Of course, I don't see any better way to fix this, but it would be
 > interesting to see what effect (if any) this change has on
 > Dacapo/SpecJVM scores.

OK, but I suspect the affect of this change will be in the noise.

Andrew.