[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Japitools status - Savannah and v5 support

From: Stuart Ballard
Subject: Japitools status - Savannah and v5 support
Date: Wed, 27 Oct 2004 11:42:38 -0400
User-agent: 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 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]