critical Java regression

Mon Apr 22 21:26:00 GMT 2002

Mark Wielaard wrote:
> Ugh, nasty. The reason it fails to see that the class is already loaded
> is because the first time it loads ../../gnu/math/RealNum.class, but the
> second time it loads RealNum.class from the current directory.
>> The first time it tries to read RealNum is when it resolves the RatNum
> which has as superclass RealNum. The second time it tries to resolve
> RealNum.toScaledInt, which makes it look for the class RealNum which
> thinks to finds in the no-name package.
>> A quick workaround seems to be to just ignore this and only issue a
> warning when coming across a second class file that defines the same
> class.

I think there may be two separate more fundamental: RealNum.toScaledInt
cannot possibly a class name, because of context (before a '(').
According to the Names chapter of the JLS, RealNum.toScaledInt is
unambiguously a MethodName. Now RealNum is an AmbiguousName, but if
we're trying to find a class RealNum.toScaledInt we're probably going
about it the wrong way.
Thus there is a bug in how qualify_ambiguous_name calls
resolve_and_layout: We should never call resolve_and_layout on
RealNum.toScaledInt in this case.
Now suppose we see 'RealNum.Foo.Bar('. In this case RealNum.Foo
is an AmbiguousName. However, the JLS is quite clear that to
classify an AmbiguousName RealNum.Foo you *first* have to
classify RealNum. So again, looking for a class RealNum.Foo
without having *first* resolved RealNum is wrong.
-- 
	--Per Bothner
per@bothner.com http://www.bothner.com/per/