Re: Japitools status - Savannah and v5 support

[Stuart Ballard]

Tom Tromey wrote:
> Eventually you could consider using code from gcjx ("Eventually"
> because the 1.5 bytecode-reading support hasn't been written yet).  In
> this case you'd have to write in C++ and not Java.  OTOH, the part of
> Japi to generate the .japi file could be rewritten as a gcjx back end
> without much difficulty.  (In fact it could be arranged so that a Japi
> output file is created as a side effect of building the .class files;
> gcjx can already run multiple back ends for a single compilation.)

Might be an interesting excuse to learn C++. I'll bear it in mind as a 
possibility if nothing else pops up in the meantime.

> Hmm, I suppose generating serialVersionUID will be hard.

That's hard already and a suspected source of bugs - something's going 
on with AccessibleApplet that's not currently understood AFAIK.

> One thing we may want to consider is the goal of Japi.  If it is
> binary compatibility, then most of the questions below aren't too
> relevant -- because generics work by type erasure, the
> parameterizations are not visible at runtime and thus don't affect
> binary compatibility.  For instance, it is binary (but not source)
> compatible to change a generic class to be non-generic.
>
> Source compatibility is not defined by the spec, but "we know what it
> is" -- basically that the user-visible envelope of classes in the
> standard library should be the same in every meaningful way.

Full source compatibility is almost impossible because you can't add any 
new names to a non-final class without potentially screwing stuff up 
royally. Besides, Sun broke that at a language level for anyone who had 
a variable called strictfp or a method called assert().

On the other hand, I agree that in this case following strictly binary 
compatibility with no regard for the source code implications is wrong. 
It just so happened that up to now the rules for binary compatibility 
were close enough to what we actually did want that it was reasonable to 
talk about.

Actually japicompat already has a -s flag which sticks to binary 
compatibility as defined by the JLS, without the additions for things 
like exceptions and adding methods to abstract classes. I think it would 
be reasonable to put all the generic comparisons that don't affect 
binary compatibility in the set of tests that gets excluded by this flag.

> I didn't answer your list of questions one-by-one since we would need
> to answer the goal part first.  But if the goal is source
> compatibility, which I think it should be, then basically we just want
> to keep ensuring that everything is "the same": same (possibly
> generic) types for fields, same types for method arguments and
> returns, same parameterization for generic classes, etc.

There's one definite exception to this - Sun's clearly felt free to take 
non-generic classes and add generic parameters constrained to the types 
that were already in use (see Collections, java.lang.Class etc). When 
japitools tests for backwards compatibility it should reflect the 
reality that doing this is considered "okay".

> As a first cut I would say that those which are @Documented should be
> considered as necessary for compatibility.

This sounds right.

> Enums and varargs methods.

Good call.

Stuart.

--
Stuart Ballard, Senior Web Developer
NetReach, Inc.
(215) 283-2300, ext. 126
http://www.netreach.com/