[jboss-dev-forums] [Design the new POJO MicroContainer] - Re: Retrowoven container project

[flavia.rainone@jboss.com]

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?

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4053342#4053342

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4053342