[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Japitools status - Savannah and v5 support
Japitools status - Savannah and v5 support
Wed, 27 Oct 2004 11:42:38 -0400
Mozilla Thunderbird 0.8 (X11/20040926)
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
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
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:
- 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
- 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
- How is the generic meta-information stored in the bytecode format?
- 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?
- Are there any other new 1.5 features that japitools should bear in
Stuart Ballard, Senior Web Developer
(215) 283-2300, ext. 126
- Japitools status - Savannah and v5 support,
Stuart Ballard <=