Japitools status - Savannah and v5 support

[Stuart Ballard]

I just noticed that the Savannah people have put japitools' CVS online 
(I don't think I got any notification that this had been done, but it 
might have just been spamfiltered away).

Unfortunately it seems that you still can't create new mailing lists on 
Savannah - I've asked whether there's any ETA or a workaround for this, 
but I'm not terribly hopeful, considering how long it took for them to 
start accepting new projects again after their downtime. I confess to 
being a little disenchanted with Savannah in general but I imagine that 
if any Classpath developers are interested in participating in japitools 
development they'll already have Savannah accounts, which wouldn't be 
true if I hosted anywhere else.

If anyone wants to be added to the Japitools project on Savannah, let me 
know your savannah username.

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

I'm still working on false-positive elimination from the results of 
earlier JDKs. I have a pretty good handle on exactly what needs to 
change where - it's a surprisingly deep and subtle change because if 
you're not careful it breaks a lot of assumptions about things like 
percentages adding up to 100% (what kind of moron would assume that, 
honestly? ;) )

Furthermore, I started thinking about what would be needed to get real 
support for J?SE?.? where one of those ?s is a 5 (hereafter refered to 
as "v5" to keep things simple). There are a few things that need to be 
considered here:

1) Jode in its current form cannot understand the new v5 constructs. One 
of four things needs to happen here:

  a) The CVS version of Jode may have some support for this stuff. We 
could move to it, if it does. On the other hand that version has been 
under development for years and never released, which raises obvious 
questions about how actively maintained it is. I also understand that 
the API has changed substantially (for the better - but still) so it may 
be some work to integrate.

  b) We could hack support for the new features into our local copy of 
Jode. We've done this for several bugfixes in Jode already. May be 
difficult because I, certainly, don't really understand the Jode code.

  c) We could find an alternative bytecode-reading library that already 
understands the new constructs and adapt Japize to use it. The 
adaptation process shouldn't be too hard because Japize doesn't require 
very much information out of the bytecode library - pretty much only the 
metadata, and the bytecode library is already pretty well abstracted 
because there used to be a reflection implementation.

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


2) My own understanding of the exact semantics of the new v5 features is 
much weaker than my understanding of the semantics that already existed, 
and I don't find the documentation terribly accessible. When I wrote 
japitools originally (4 years ago now) I already was pretty clear on 
exactly what could possibly exist on a class and a quick read of the 
relevant JLS section quickly crystallized my understanding of what was 
required for binary compatibility. By comparison, I've never written a 
program using the v5 constructs and may not do so any time soon, 
considering that my day job and much of my personal hacking has moved to 
C#, so I really don't have a good sense of their implications.

I sat down and tried to formulate a list of questions about v5 to figure 
out exactly what needs to be implemented, and this is what I came up with:

- Generics:
  - Are generics in Java per-class only or might they be per-method?
  - For each generic parameter, do I need to store anything beyond the 
constraining superclass?
  - Co- and contravariance?
  - When a generic parameter type is a field value, method parameter or 
return type, does anything special happen?
  - In what ways is it legal to modify generic type parameters while 
retaining binary backward compatibility? java.lang.Class<T> and the 
collections APIs demonstrate that adding generic parameters to a 
previously non-generic class is okay. How about...
    - adding new generic parameters to a class that did have them before?
    - Changing the constraining class to be more specific?
    - Less specific?
    - Anything special happen if either the parameter or the class 
*with* the parameter is actually an interface?
    - What about removing a generic type parameter - that's presumably 
forbidden?
  - How is the generic meta-information stored in the bytecode format?

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


- Others:
  - Are there any other new 1.5 features that japitools should bear in 
mind?


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