Re: Japitools status - Savannah and v5 support

[Tom Tromey]

>>>>> "Stuart" == Stuart Ballard <address@hidden> writes:

Stuart> For now, if people here don't object, I'll post occasional status
Stuart> reports on the Classpath list which would otherwise have gone to a
Stuart> japitools list.

Sounds good to me.

Stuart>    d) We could write our own bytecode-reading library to understand
Stuart>    the new constructs. Again, the fact that Japize doesn't really need
Stuart>    that much information works in our favor. Against us is the fact
Stuart>    that, at least if I write it, I know nothing about bytecode formats.

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.)

Hmm, I suppose generating serialVersionUID will be hard.


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.

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.

Stuart>    - Co- and contravariance?

... one nice thing about using gcjx as the processor for this stuff is
that you don't need to implement class inheritance, method overriding,
etc.  gcjx already does that.

Stuart>    - I have no idea. Anyone understand how annotations impact backward
Stuart>      compatibility and what information needs to be stored per class
Stuart>      and/or member to make this happen?

It depends on the annotation, they have different properties.  E.g.,
some are kept at runtime and are user-visible.  Some are
"@Documented", meaning their presence is part of the public API for
the object they modify.  Others are probably not worth tracking,
e.g. @SuppressWarnings, which is used to suppress compiler warnings
related to some source-level object.

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

Stuart>    - Are there any other new 1.5 features that japitools should bear
Stuart>      in mind?

Enums and varargs methods.

Tom