On 9/7/05, David Holmes <[EMAIL PROTECTED]> wrote: [Lots of very very useful and insightful observations and explanation snipped]
Thanks very much for taking the time to go through my examples and pick my code apart. You confirmed a lot of things I thought, and clarified a bunch of areas where I was still unsure. > > The goal is to try to compare these in a way that's meaningful both > > from a 1.4 perspective and a 1.5 perspective. However... > > I don't quite follow the problem here, in that if you are processing a > parameterized 1.5 type then you need to apply the 1.5 rules regarding > overloads, overrides, covariant returns and allow for bridge methods (which > should be marked as such). Unfortuanately this is the crux of the problem. Japitools needs to keep a foot in both camps - we need to be able to answer questions like "how well is Classpath's main branch (which is non-generic and living in the 1.4 world) doing at providing API compatibility with JDK 1.5?" What it comes down to is that I need to find a way to apply both sets of rules simultaneously, and figure out which problems are real problems and which are just artefacts of the different sets of rules. When I compare a 1.4 implementation of java.util.List against 1.5's java.util.List<T>, the comparison should accurately identify the fact that the implementation is largely correct, while also flagging the fact that all the generic parts are missing. A comparison in the other direction should result in essentially no errors because (except when Sun screws up) 1.5 should be completely backward compatible with 1.4. Of course these cases are straightforward compared to what happens if you try to compare a hypothetical 1.4 versus 1.5 implementation of my Super<T>, Sub1, Sub5 and Sub8 classes. It's true that situation probably wouldn't come up in practice but in my experience if I can't answer what should happen in a corner case, it's usually a sign of a deeper design problem that will bite me eventually. > You need to know whether you are applying 1.4 or 1.5 rules regardless, to > deal with covariant returns and varargs. It's true that generics aren't the only issue where japitools gets into difficulty due to the need to live in both worlds, but generics seem to have the most tricky corner cases to figure out... > Hope this helps. Generics are so much fun - NOT! :-) I have to say, I'm glad I mostly work in C# these days. Much as I hate to credit Microsoft, they did generics *sooo* much better. > Oh a final warning: javac at least still contains many bugs with regard to > generics. What you observe need not be what the language truly allows or > prohibits. Can't speak for the other compilers. Hopefully it can at least accurately cover anything that will show up in the standard class libraries, which is the most important for japitools to cover correctly... Stuart. -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
