On 9/7/05, Casey Marshall <[EMAIL PROTECTED]> wrote: > From this description it kind of sounds as though JVML (that is, > bytecode) defies the kind of static analysis Japitools is trying to > do. At least, when you aren't guaranteed to have the entire class > tree down to Object.
Sort of... As you may or may not know, japitools runs in two phases: Japize, which takes a bunch of classfiles and turns them into a .japi file, and japicompat which compares two japi files for compatibility. Japize *is* guaranteed to have access to the entire tree down to Object. japicompat only has whatever Japize puts in the japi file, and Japize only puts the classes that it's told to include. In order to make this work, Japize puts *all* members of the classes into the japi file - not just the ones declared at that level, but anything inherited from superclasses too. When japicompat compares these lists, therefore, it's almost exactly equivalent to the JVM logic: if the list of members consists of all the superclass members as well as those declared in the class itself, comparing those members is equivalent to walking the superclass chain. > Maybe it would be a useful tool that took two sets of class files, > and compared them for binary compatibility, applying the same > semantics that would be used when looking up methods or fields when > run in a VM. That is, each available method or field in the base set > would be looked up in the target one, to see if it is equivalently > accessible. If I understood that right, I think it's what japitools does. It's what I *try* to achieve anyway. > I guess this might produce, uh, interesting results, > where Classpath might prove entirely binary compatible, but not > source compatible, so you could run binaries against Classpath, but > not compile them ;-) (I'm no JVM expert, so I don't know if this is > true). I think it's theoretically true. I'm not sure how much of a problem it is in practice, however. > But anyway, it is best to target meaningful compatibility issues, and > to do that in a tractable way. So, what does API compatibility mean > as far as Classpath is concerned? And what is the best (or easiest) > way to test that? Exactly the goal I've had with japitools. The problem is that in the generic world there's all these weird corner cases that I'm not quite sure what to do with. Java's generics live in a kind of limbo state halfway between binary and source compatibility, and trying to represent that reasonably in a format designed for pure binary compatibility checking, and still produce meaningful results on the generic part, is tough. As far as my particular question, I'm beginning to feel that the file format needs to allow for specifying both types - the "real" type and the one that applies in fairyland. Something like this: pkg.name,Sub!foo(Ljava/lang/Object;=Ljava/lang/String;) Then the full set of information is available to japicompat. Exactly what it should *do* with that information isn't quite clear, but at least we're not eliminating the information before it gets a chance to make an informed decision. Stuart. -- http://sab39.dev.netreach.com/ _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
