JBoss development, A new message was posted in the thread "JBREFLECT-5 - Implementing generics in JavassistClassInfo": http://community.jboss.org/message/529467#529467 Author : Kabir Khan Profile : http://community.jboss.org/people/kabir.khan@jboss.com Message: -------------------------------------------------------------- I have had a first stab at implementing generics in the Javassist version of ClassInfo and committed it against http://jira.jboss.org/jira/browse/JBREFLECT-5.   I have created Javassist versions of the tests that were not there before: JavassistGenericClassUnitTestCase and JavassistGenericInterfaceUnitTestCase. They are just subclasses of the abstract base classes used by the Introspection versions of these tests. They pass, but I don't think that they are good enough for the following reasons:   1) They only test plain generics such as Collection<String>, while more complex things such as Collection<Map<String, List<V>>> are not tested.   2) Wildcards and bounds are not tested, but I am not sure if we should support those or not?   3) When accessing generics from the return type of a method, e.g.        Collection<String> getStringCollection(){}   we get hold of this method using normal reflection (A) and construct the TypeInfo for that using the ParameterizedType (B1+2) for which I extended the Javassist TypeInfo factory:    private void assertComponentType(String methodName, Class<?> expected) throws Exception    {       Method method = ClassInfoGenericClassTest.class.getMethod(methodName, (Class[]) null); //A       Type type = method.getGenericReturnType(); //B1       assertComponentType(type, expected);    }      private void assertComponentType(Type type, Class<?> expected) throws Exception    {       TypeInfoFactory factory = getTypeInfoFactory();       TypeInfo typeInfo = factory.getTypeInfo(type); //B2       ClassInfo classInfo = assertInstanceOf(typeInfo, ClassInfo.class);       assertTrue(classInfo.isCollection());         TypeInfo expectedInfo = factory.getTypeInfo(expected);       assertEquals(expectedInfo, classInfo.getComponentType());    } However, that is probably not what will happen in real life, we would have a ClassInfo, get hold of the MethodInfo in question, and then get the return type which should contain the actualTypeArguments. This needs implementing and is not being tested at the moment, and the same goes for parameters and field types. 4) Flavia mentioned that for the component type tests we might have something like interface WeirdMap<V, K> implements WeirdMap<K, V> This is kind of tested but needs fleshing out more What I have do so far satisfies what the tests require, but in case somebody looks at this while I look at the aop failures in AS trunk, feel free to rework and change what I have done, it is by no means the final solution although I think it proves that the stuff Chiba did for the Signature attribute works well and we can figure out things from that. A few points worth remembering: a) I have implemented a JavassistParameterizedClassInfo (stolen from the introspection implementation) which handles things like Collection<String>. This basically delegates to the "raw" ClassInfo for Collection, augmented with extra information regarding the <String> bit. These are currently not cached and are created on every access. b) JavassistClassInfo should cache the values of isMap() and isCollection() -------------------------------------------------------------- To reply to this message visit the message page: http://community.jboss.org/message/529467#529467