I've put an initial updated version of the file format specification (with lots of XXXXs for things we haven't worked out yet) at http://savannah.nongnu.org/cgi-bin/viewcvs/japitools/japitools/design/japi-spec-0.9.7.txt?rev=1.1&content-type=text/vnd.viewcvs-markup
Compare with the current japi specification, http://savannah.nongnu.org/cgi-bin/viewcvs/japitools/japitools/design/japi-spec.txt?rev=1.7&content-type=text/vnd.viewcvs-markup
Beyond the changes in this file we're starting to look at the representations of generic types. My initial suggestion (which Jeroen happily shot to pieces :) ) was as follows:
We need to add various things to the concepts we can represent:
1) The fact that a class or interface has generic parameter types. I think this could be represented by putting the constraining type in the typeinfo section:
java.util,ArrayList! Pcsnu class<java.lang.Object>#9999...
(where everything after the "#" is the same as it is now, ie 9999 is just an example svuid because I can't be bothered to look up the right value for arraylist).
Multiple generic parameters would be comma-separated, eg:
java.util,HashMap! Pcsnu class<java.lang.Object,java.lang.Object>#99...
(An open question: should inner classes be treated as inheriting their containing class's generic parameter types or not? The best answer here depends on how it's actually implemented. Is there such a thing as, say, Map<int,String>.Entry, or is it Map.Entry<int,String>? Or does the former exist but just as an illusion where the real implementation uses the latter?)
2) The fact that a particular class *is* one of those generic parameters from the containing class. This applies to types represented in Java Language Representation and to types represented in Type Signature representation. I don't know whether they appear at all in real type signatures (I'm guessing not because of the Type Erasure generics model) but if not then they can be represented the same way in both. I'm thinking as @0 @1 etc.
3) The fact that a particular class is a generic class with specific values of its parameter types. This also applies to types represented in Java Language representation and in Type Signature representation. Again, I'm assuming generics don't appear at all in real type signatures so I'm free to do whatever I want here.
For Java Language representation it makes sense to follow the java language as much as possible, which suggests simply using the name of the type followed by its parameter types, comma separated, in Java Language representation, enclosed in <>. This suggests that the superclasses and interfaces for ArrayList go something like:
java.util,ArrayList! Pcsnu class<java.lang.Object>#999:java.lang.AbstractList<@1>:java.lang.Object*java.util.List<@1>*java.util.Collection<@1>*java.io.Serializable
For Type Signature representation I'm thinking we can do something similar but insert the <> before the trailing ";". We can still put the parameters in in Java Language representation because primitive types aren't permitted as part of generics. So if a method returns a List<String> it would have its return value listed as "Ljava/util/List<java.lang.String>;". If that were an array of List<T> where T is the first generic type parameter it would be "[Ljava/util/List<@1>;". Obviously if it returned T it would be listed as just "@1".
Item 1 here has a major problem in that it can't represent anywhere near all the possible constraints that can be applied to a generic type parameter. Some examples Jeroen gave that need to be representable in whatever representation we choose:
class gen1<T extends Comparable & Runnable> {}
class gen2<T extends Comparable<T>> {}
class gen3<T extends java.util.Set<? extends Runnable>> {}
class gen4<T extends java.util.Set<? super T>> {}
The "open question" seems to have been closed with the answer that inner classes do inherit generic parameters from their container and should be treated as such.
Item 2 may be okay as long as the numbering scheme can cope with the inheritance to inner classes.
Whether item 3 is okay or not depends on what is allowed to be specified in that situation - especially whether the "?" syntax is permissible in regular types. Can you have a method that takes a Set<? super T> as a parameter or returns a Set<? extends Runnable>? If either of these are possible then this proposal needs more work; if not then it may be adequate as-is.
We haven't started discussing how to represent classes and members with annotations attached yet.
Anyone have any feedback or suggestions?
Stuart. -- Stuart Ballard, Senior Web Developer NetReach, Inc. (215) 283-2300, ext. 126 http://www.netreach.com/
_______________________________________________ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
