alesj wrote:

 

1) It should be easy to add some tests for this, right?

Perhaps we use some on-the-fly generics creation (which Javassist has, afaik), and test this for some reasonable depth.

Yes

Not sure I understand the question. I've just worked with what was provided, but we need some tests testing the scenario I outlined. We would need to check the Signature attribute of the method and then construct the parameterized ClassInfo as was done for getGenericSuperClass().

The main thing is knowing the index of the type parameter we are looking for in the parent class, then getting the type argument using that index used when extending that class and matching that up with the type parameters of the child class. This needs doing for the whole hierarchy. This has been done, but needs some better tests

I'll try that

kabir.khan@jboss.com wrote:

 

 

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.

Looking properly, I think what is there at the moment is correct. In reflect we have these additional methods:

Type[] Method.getGenericExceptionTypes()

Type[] Constructor.getGenericExceptionTypes()

Type[] Method.getGenericParameterTypes()

Type[] Constructor.getGenericParameterTypes()

Type Method.getGenericReturnType()

Type Field.getGenericType()

I have not added caching yet, and adding this simple test passes with the introspection implementation, but fails with the Javassist implementation

   public Comparable<String> signatureCachedParameterizedClassInfo()
   {
      return null;
   }
   
   public void testCachedParameterizedClassInfo() throws Throwable
   {
      Type type = getGenericReturnType("signatureCachedParameterizedClassInfo");
      TypeInfo typeInfo1 = getTypeInfoFactory().getTypeInfo(type);
      TypeInfo typeInfo2 = getTypeInfoFactory().getTypeInfo(getGenericReturnType("signatureCachedParameterizedClassInfo"));
      assertEquals(typeInfo1, typeInfo2);
      assertSame(typeInfo1, typeInfo2);  // <-- FAILS

      //Also check the results of repeated calls to getGenericSuperClass/-Interfaces() etc.
   }

 

Is this object equality a requirement? My fear is that working out the key will be costly

This has been done.

kabir.khan@jboss.com wrote:

 

2) Wildcards and bounds are not tested, but I am not sure if we should support those or not?

 

Note to self: When I get round to this, I should check both interface and class bounds

alesj wrote:

 

As all of the stuff in Reflect works this way, why is this here a problem?

Not really a problem, I just wanted to check if the object equality is required. It seems to work that way normally, so I'll do that for this instead as well.

kabir.khan@jboss.com wrote:

 

2) Wildcards and bounds are not tested, but I am not sure if we should support those or not?

It looks like they should be supported, since the following quick test passes with the Introspection implementation, but needs some work in the Javassist implementation:

   public static Collection<?> signatureCollectionUnboundedWildcard() 
   {
      return null;
   }
   public void testComponentTypeCollectionUnboundedWildcard() throws Throwable
   {
      assertComponentType("signatureCollectionUnboundedWildcard", Object.class);
   }

I'll write some proper tests for this and implement in Javassist

One thing I have been doing which might be unnecessary is to wrap things with wildcards with a delegating class, e.g.:

/**
 * Type info for a wildcard type
 * 
 * @author <a href="kabir.khan@jboss.com">Kabir Khan</a>
 * @version $Revision: 1.1 $
 */
public class WildcardTypeInfo extends DelegateClassInfo
{
   private static final long serialVersionUID = 1L;

   private final String name;

   public WildcardTypeInfo(String name, ClassInfo delegate)
   {
      super(delegate);
      this.name = name;
   }

   @Override
   public void toShortString(JBossStringBuilder buffer)
   {
      buffer.append(name);
   }

   @Override
   protected void toString(JBossStringBuilder buffer)
   {
      buffer.append("name=").append(name);
   }
}

So if you try to get the typeInfo for Class<? extends some.Thing> we end up with a ParameterizedClassInfo for Class which contains one type argument. This type argument is for some.Thing. The original introspection implemetation would just use that directly. What I am doing now is to

get the TypeInfo for some.Thing (1) and decorate that with a WildcardTypeInfo that delegates to 1, but has the name '? extends some.Thing' which is ONLY used in these two cases:

• invoking toString().
• looking up the WildcardTypeInfo in the cache

The reason I am unsure if this is needed after all is that I am currently implementing TypeVariables, e.g.:

public <T extends some.Thing> T signatureMethod()

If I were to wrap it, I would end up with 1 and wrapping that with a TypeVariableTypeInfo which overrides toString with 'T extends some.Thing'. The problem is that if we also have

public <U extends some.Thing> T signatureMethod2()
public <V extends some.Thing> T signatureMethod3()

In case I was not clear, if I have

<T extends some.Thing> sig1()

I am trying out the javassist implementation in kernel now. The first stumbling block is this

java.lang.RuntimeException: Unable to create a KernelInitializer based on the specified KernelConfig

at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:156)

at org.jboss.kernel.KernelFactory.assembleNewKernel(KernelFactory.java:99)

at org.jboss.kernel.KernelFactory.newInstance(KernelFactory.java:67)

at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.bootstrap(AbstractBootstrap.java:114)

at org.jboss.kernel.plugins.bootstrap.AbstractBootstrap.run(AbstractBootstrap.java:83)

at org.jboss.test.kernel.bootstrap.test.BootstrapTestCase.testBasicBootstrap(BootstrapTestCase.java:76)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:597)

at junit.framework.TestCase.runTest(TestCase.java:168)

at junit.framework.TestCase.runBare(TestCase.java:134)

at junit.framework.TestResult$1.protect(TestResult.java:110)

at junit.framework.TestResult.runProtected(TestResult.java:128)

at junit.framework.TestResult.run(TestResult.java:113)

at junit.framework.TestCase.run(TestCase.java:124)

at junit.framework.TestSuite.runTest(TestSuite.java:232)

at junit.framework.TestSuite.run(TestSuite.java:227)

at junit.extensions.TestDecorator.basicRun(TestDecorator.java:24)

at junit.extensions.TestSetup$1.protect(TestSetup.java:23)

at junit.framework.TestResult.runProtected(TestResult.java:128)

at junit.extensions.TestSetup.run(TestSetup.java:27)

at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81)

at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:46)

at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)

at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)

Caused by: java.security.AccessControlException: access denied (java.lang.RuntimePermission getClassLoader)

at java.security.AccessControlContext.checkPermission(AccessControlContext.java:323)

at java.security.AccessController.checkPermission(AccessController.java:546)

at java.lang.SecurityManager.checkPermission(SecurityManager.java:532)

at org.jboss.reflect.plugins.javassist.JavassistTypeInfo.getClassLoader(JavassistTypeInfo.java:211)

at org.jboss.classadapter.plugins.BasicClassAdapter.getClassLoader(BasicClassAdapter.java:70)

at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:136)

at org.jboss.beans.info.plugins.AbstractBeanInfoFactory.getBeanInfo(AbstractBeanInfoFactory.java:124)

at org.jboss.config.plugins.AbstractConfiguration.getBeanInfo(AbstractConfiguration.java:69)

at org.jboss.kernel.plugins.config.AbstractKernelConfig.getBeanInfo(AbstractKernelConfig.java:65)

at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.getImplementation(PropertyKernelConfig.java:184)

at org.jboss.kernel.plugins.config.property.PropertyKernelConfig.createKernelInitializer(PropertyKernelConfig.java:121)

at org.jboss.kernel.KernelFactory.createKernelInitializer(KernelFactory.java:150)

... 28 more

JavassistTypeInfo:

   /** The get classloader permission */
   private static final RuntimePermission GET_CLASSLOADER_PERMISSION = new RuntimePermission("getClassLoader");
..
   public ClassLoader getClassLoader()
   {
      // looks like Javassist ClassPool::getClassLoader
      // doesn't check for security, so we should
      SecurityManager sm = System.getSecurityManager();
      if (sm != null)
         sm.checkPermission(GET_CLASSLOADER_PERMISSION);
      return JavassistUtil.getClassLoader(ctClass);
   }
 

In the introspection implementation this simply delegates to Class.getClassLoader()

    public ClassLoader getClassLoader() {
        ClassLoader cl = getClassLoader0();
        if (cl == null)
            return null;
        SecurityManager sm = System.getSecurityManager();
        if (sm != null) {
            ClassLoader ccl = ClassLoader.getCallerClassLoader();
            if (ccl != null && ccl != cl && !cl.isAncestor(ccl)) {
                sm.checkPermission(SecurityConstants.GET_CLASSLOADER_PERMISSION);
            }
        }
        return cl;
    }

getClassLoader() gets called quite a bit, and I am unsure how best to handle this?