Retrowoven container project

[kabirkhan]

A few of the JDK 1.4 tests in AOP are failing due to java.lang.reflect.ParameterizedType being used by the container project. while not supported in JBoss Retro. I tried adding that to Retro, but it now falls over on things like:

java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
java.lang.NoSuchMethodError: java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:143)
at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:400)
at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getConstructors(AbstractBeanInfoFactory.java:177)
at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:138)
at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:75)
at org.jboss.test.beaninfo.test.AbstractBeanInfoTest.getBeanInfo(AbstractBeanInfoTest.java:349)
at org.jboss.test.beaninfo.test.BeanInfoUnitTestCase.testBean(BeanInfoUnitTestCase.java:153)
at org.jboss.test.beaninfo.test.BeanInfoUnitTestCase.testBeanConstructors(BeanInfoUnitTestCase.java:73)
at junit.extensions.TestDecorator.basicRun(TestDecorator.java:22)
at junit.extensions.TestSetup$1.protect(TestSetup.java:19)
at junit.extensions.TestSetup.run(TestSetup.java:23)

So support for this needs implementing

[starksm64]

Can you create a test for this and add a jira issue to http://jira.jboss.com/jira/browse/JBBUILD under the JBossRetro component so it does not get lost.

[adrian.brock]

This also needs linking with this:
http://jira.jboss.com/jira/browse/JBMICROCONT-129
I'm not sure what support Javassist has for the Java5 types?

[kabirkhan]

http://jira.jboss.com/jira/browse/JBBUILD-333

Javassist doesn't seem to have any built in support for the types, but they seem to be tied in somehow with the Signature attribute.

[chiba]

OK, I will fix this problem.

[chiba]

java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
java.lang.NoSuchMethodError: java.lang.reflect.Constructor.getGenericParameterTypes()[Lorg/jboss/lang/reflect/Type;
at org.jboss.reflect.plugins.introspection.IntrospectionTypeInfoFactoryImpl.getConstructors(IntrospectionTypeInfoFactoryImpl.java:143)
at org.jboss.reflect.plugins.ClassInfoImpl.getDeclaredConstructors(ClassInfoImpl.java:400)

It seems that the underlying JVM is 1.4 and thus does not support getGenericParameterTypes(). Is this correct?
If yes, Javassist is not guilty of this problem. (Of course, Javassist should
provide some support of generic types but I am now writing about this particular problem.)

[kabirkhan]

When used with JBoss Retro, we will replace access to Constructor.getGenericParameterTypes() with a call to some other class that does this. We will also replace all occurrences of java.lang.reflect.Type with org.jboss.lang.reflect.Type etc.

The "some other class that does this" will need to use javassist to get hold of the generic info, similarly to how the JBoss Retro AnnotationHelper uses javassist to get hold of the annotations from the bytecode attributes.

[flavia.rainone]

The main difficulty of implementing the generic reflection methods is the fact that java.lang.Class does not extend java.lang.reflect.Type.
Kabir and I have been discussing about this issue in the past few days.
I decided to play a little with the code Kabir attached to Jira
http://jira.jboss.com/jira/browse/JBBUILD-333

The generic API Kabir implemented is returning java.lang.Object where java.lang.Type is expected. This approach works fine, except for the following scenario:

final Type[] OBJ_TYPE_ARR = new Type[] {Object.class};

which results in java.lang.ArrayStoreException

I can think of three solutions for this problem:

(1) do nothing, leave as is, and add the scenario above as a restriction in the usage of jboss retro
pros: simplicity
cons: we are not solving the problem above

(2) change bootclasspath, in a similar way we do in Jboss AOP to affect
java.lang.ClassLoader. In a very simple way, we could make Class to implement Type, and make Class, Method and Constructor to implement GenericDeclaration.
pros: simple solution and solves the problem
cons: we are forcing users to set xbootclasspath everytime they run a retro woven code

(3) replace java.lang.Class by a org.jboss.retro.runtime.lang.Class
pros: problem solved
cons: problem of casting (explained below)
affects performance
complex solution

After playing with the replacement of java.lang.Class for a while, I have an almost ready version. Nevertheless, there is a lot of details involved that I had to solve. The code looks too complex, and it does not work completely. It will fail in the following scenarios:

Class clazz = (Class) list.get(0); // if this list has been returned by an api, and it contains java.lang.Class instances, we have a problem, we need to wrap the element in a org.jboss.retro.runtime.lang.Class instance
Class clazz = (Class) Biblio.doSomething(); // same here, this time it is an api method that returns Object

In order to solve the problem with the code above, we would need to detect those class casts and wrap the java.lang.Class in a jboss retro class.

All in all, I think that we should leave as is, unless ArrayStoreException be considered a very serious issue. Another possibility would be to provide the bootclasspath solution as an option, so that, if there is a problem with an woven code due to java.lang.Class not implementing org.jboss.retro.runtime.lang.Type, there would be a solution available.

Any thoughts?

[pgier]

How about translating Type to java.lang.Object? Since the jdk1.5 Type interface does not have any methods, you don't seem to lose any functionality. So the code above becomes

final Object[] OBJ_TYPE_ARR = new Object[] {Object.class};

If you get the latest jboss retro from svn, this is how I have it working now. Combined with kabir's code, this seems to work. At least for the test cases I came up with.

Maybe we lose something else that I'm not thinking of.

[flavia.rainone]

Great! When I looked at the retro trunk code, I just noticed I couldn't find the problematic line at the test class anymore. I didn't realize that you were replacing java.lang.Class by java.lang.Object :)

Your idea is really good. Maybe, you could apply the same to GenericDeclaration. Replace it by Object, and replace calls to its single method (getTypeParameters) by calls to a Helper, as is done in GenericsHelper. That way, all the problem would be solved, and in a very simple way.

[pgier]

Ok, I should be able to add the GenericDeclaration stuff today. And then I will release retro 1.1.0 at the end of today or tomorrow.

[flavia.rainone]

Excelent news! :)