Eager vs Lazy resolution of classes

Wed Jul 21 23:03:00 GMT 2004

Chris Gray wrote:
>On Wednesday 21 July 2004 16:01, Bryce McKinlay wrote:
>>>>Chris Gray wrote:
>>>>>>>It became clear that Java developers think it normal that a class which
>>>contains references to all sorts of non-existent classes should run just
>>>fine provided those code paths are never traversed. So my guess is that
>>>this one will come to bite you sooner rather than later.
>>>>>>>>This is a different issue. There is no problem with unresolvable
>>references on code paths which are never actually traversed, because the
>>spec requires that such errors are not thrown until active use. The
>>BC-ABI was designed for this from the outset.
>>>>>>OK, that's fine. From my experience you'll also need to to tolerate 
>unrsolvable types as arguments of methods that are never called, interface 
>methods which a class should implement but doesn't (but the methods are never 
>called), etc., all in the name of robustness in the face of version skew.
>>Right. This stuff is specified in the binary compatibility spec (aka 
"chapter 13").
>>The issue here is whether it is ok to do the resolution itself eagerly,
>>deferring errors until active use. That is, whether new classes can
>>appear on the classpath at runtime, after the class that uses them has
>>already been linked, and expect to be resolved successfully.
>>>>>>IMO any code that relies on this behaviour is broken. If that means that some 
>Eclipse 2.x versions were broken and Eclipse 3 is not, then that shows that 
>the Eclipse guys are learning as they go along.
>>I agree. I think we could actually support this stuff with the BC-ABI, 
but we'd have to jump through some hoops to do it. As Andrew suggests, 
it is something that could be added later, if it proves neccessary, 
provided we don't do anything to preclude it.
Regards
Bryce