[DrJava] It was not covariant subtyping, by the way

[Brian S. <bs...@bs...>]

As Eric point out to me, the build problem was not covariant subtyping
(which causes us other problems due to our javadoc process). It was the
specialization of a parametric class -- that is, creating a class like:

class Foo extends Bar<A> {}

Foo has no parameters; it has locked its superclass Bar's parameter to A.
But if you recompile uses of Foo without Foo itself being compiled, the
compiler sometimes doesn't understand that the Bar methods inside Foo know
that the parameter is A. This results in some messages telling you that
some methods were not found, usually in java.lang.Object (the upper bound
of the type parameter). This is an irritating bug and relates to the GJ
implementation of erasure for parametric types.

The relevant code was in model.definitions.reducedmodel. In particular,
the weirdness showed up in ReducedModelComment, where it was trying to
call methods on the result of TokenList.current(). TokenList extends
ModelList<ReducedToken>, so it's reasonable to try to call ReducedToken
methods on the result of .current(). However, the compiler got confused
(because ReducedModelComment changed but TokenList did not) and didn't
realize that the return type of .current() was in fact ReducedToken.

Anyhow, this is probably a lot more than you cared about, but just in
case. :)

-brian

----------------------------------------------------------------
Brian Stoler       home: (713) 520-9017   office: (713) 348-3720
Graduate student, Rice University Department of Computer Science