Re: Japitools 1.5 support tough design issue

[Stuart Ballard]

On 9/7/05, Casey Marshall <address@hidden> 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/