On 1/26/06, Roman Kennke <roman@xxxxxxxxxx> wrote: > Hmm, when it compiles fine against JDK1.5 and fails with Classpath, it > seems to me that this field should show up in the forward JAPI instead? This is a good point. The problem is that as a point of principle I try *very* hard to avoid putting any information into japi files that could be considered an implementation detail. I think this is very important because it's the main basis on which I can state with confidence that the JDK japi files are freely distributable, as opposed to being "derived works" of the JDKs that they represent. As long as they contain only functional information necessary for interoperability, that information is un-copyrightable and hence so is the japi file. If we put in any implementation details, that opens us up to the claim that the japi file contains copyrighted information and we're not allowed to distribute it. In *almost* every case, the existence of a private field is an implementation detail, so japi provides no way to represent them. I suppose we could add a specific representation to say that a private (or package-private) field shadows a public inherited field, and store absolutely no information about the private field except for its name. That would make it possible to detect this situation in the forward japi file. Otherwise, this situation is indistinguishable from an extra field being added in classpath, which is totally legal in the forward comparison. > OTOH, if the Sun javac produces broken code, and the ECJ probably > doesn't compile correctly (should refer to node.accessibleParent, no?), > then this is maybe not super important anyway. Right :) The extra complexity in the japi file to detect and represent private shadowing fields is probably not worth the effort, especially if we are going to try to get the reverse comparison down to zero errors too :) Stuart. -- http://sab39.dev.netreach.com/
