but first - Impact of debugging on Generics
                Current generics proposal and implementation includes
                class-file attributes for generic class signature 
                and generic member signature but do not 
                provide generic type info for local variables.  Thus
                one additional attribute will need to be added.

        Impact on JVMDI
                JVMDI will need to be extended to provide access to 
                the three new attributes needed for generics.  An
                alternative is adding functionality to JVMDI to 
                extract arbitrary attribute information, but this
                has two problems: it is extremely complex and 
                a random VM may not keep this information or may
                not keep it in a compatible form.

        Impact on JVMDI implementation (aka HotSpot)
                The above changes to JVMDI would need to be added
                to our VM.

        Impact on JDWP
                JDWP would need to be extended to transport this information.
                Either it would need to be packaged out of context or the
                it could be added consistently but this would break 
                compatibility and the JDWP version would need to be reved.

        Impact on back-end and front-end
                They would need to be extended to traffic in this information.

        Impact on JDI
                The impact of class use vs. class reference (see below) is 
                significant on the JDI because types are transparent.  

                Design will take some head scratching and maybe more 
                discussions.  My first impression is that it will
                require several new interfaces and also functionality 
                replicated for generics.  

                Two new sub-interfaces of Type will need to be added.
                Their exactly structure will need to be carefully
                considered so that existing debuggers "fail" as gently
                as possible.  Several other methods will need to be
                added to Method, ReferenceType, Type, ...

                Examples of functionality replication, in Method 
                argumentTypes() and returnType() are defined; 
                genericArgumentTypes() and genericReturnType() would 
                need to be added.  This could be rather ugly.  

        Impact on JDB tool
                JDB should be reved to use the above new JDI functionality,
                this should be minor.  More problematic is the impact on the
                expression evaluator (parser/interpretor). The parser would
                need to be overhauled.  The interpreter currently cheats wrt
                type information, were it to be made correct this would add
                significant work.  This was not our plan; our plan was to
                move expression evaluation down to the back-end.  Generics
                would complicate this.

Class use vs. class definition
        Where class definition is for example (of Collection):

                public interface Collection { ... }

        And class use is for example (of Collection in Map):

                public Collection values();

        Both JDI and the Doclet API use class objects (aka class definition
        objects) to represent class uses.  For example, method objects
        in both cases have a method:

                Type returnType()

        Where one subclass of Type is a class  customer .  This works great in
        Java as we know it.  In generic Java, the above definitions might
        look something like (forgive the simplification):

                public interface Collection<A> { ... }

                public interface Map<A,B> { ... 
                        public Collection<B> values();
                }

        Here the use "Collection<B>" is not the same as the definition 
        "Collection<A>".
  xxxxx@xxxxx   2001-03- customer 

N/A

see description.