Getting to a ClassInfo's ClassLoader

[flavia.rainone]

Ales,

Currently, whenever I need to get to the ClassLoader of a ClassInfo object, I use geType().getClassLoader(). The point is that getType is deprecated. Is there any other way of getting the ClassInfo's classloader without going through getType()?

[alesj]

How do we use it elsewhere/before?

Looking at the Javassist Reflect usage, it seems we need to change it a bit.

 public Class<? extends Object> getType()
 {
 if(clazz == null)
 clazz = JavassistUtil.ctClassToClass(ctClass);

 return clazz;
 }

This first delegates the loading to JavassistUtil.class.getClassLoader() and only then to CtClass::toClass.
Meaning we wouldn't use our new Classpool notion first, only after it would fail via first try.

Perhaps new getClassLoader method on TypeInfo?

btw: don't forget to check for security or add permission blocks on who can use it

[flavia.rainone]

"alesj" wrote:
How do we use it elsewhere/before?

Before I added those getType.getClassLoader() calls, the null classloader was being used for loading and creating ctClasses instead.
I don't think that classloader is retrieved elsewhere,apart from BasicClassAdapter.getClassLoader(), that also invokes getType() to get to the ClassLoader.

"alesj" wrote:
Looking at the Javassist Reflect usage, it seems we need to change it a bit.

 public Class<? extends Object> getType()
 {
 if(clazz == null)
 clazz = JavassistUtil.ctClassToClass(ctClass);

 return clazz;
 }

This first delegates the loading to JavassistUtil.class.getClassLoader() and only then to CtClass::toClass.
Meaning we wouldn't use our new Classpool notion first, only after it would fail via first try.

Don't you mean that, if the ModifiableClassInfo is modified, it delegates the loading to CtClass::toClass first, and only then to the JavassistUtil.class.getClassLoader()?
IMO, this is correct, given that CtClass.toClass() uses the ClassPool and the ClassLoader associated with the ClassPool in order to load the class.
Still, the JavassistUtil class contains a few bugs, because it is not using the correct classpool on the remaining methods.

"alesj" wrote:

Perhaps new getClassLoader method on TypeInfo?

I think that that is the ideal. The getType method has the collateral effect that the MutableClassinfo can no longer be edited after it has been loaded. The correct way of retrieving the class loader would be:

ctClass.getClassPool().getClassLoader

This could be easily done if we added a getClassLoader() method to TypeInfo.

"alesj" wrote:
btw: don't forget to check for security or add permission blocks on who can use it

Ok!

[alesj]

Don't you mean that, if the ModifiableClassInfo is modified, it delegates the loading to CtClass::toClass first, and only then to the JavassistUtil.class.getClassLoader()?
IMO, this is correct, given that CtClass.toClass() uses the ClassPool and the ClassLoader associated with the ClassPool in order to load the class.
Still, the JavassistUtil class contains a few bugs, because it is not using the correct classpool on the remaining methods.

If modified, we just try if we can still load it.

 if(ct.isModified())
 {
 try
 {
 ct.toClass();
 }
 catch (CannotCompileException e)
 {
 throw new org.jboss.reflect.spi.CannotCompileException(e.toString());
 }
 }

And yes, JavassistUtil definitely needs fixing.

"alesj" wrote:

Perhaps new getClassLoader method on TypeInfo?

I think that that is the ideal. The getType method has the collateral effect that the MutableClassinfo can no longer be edited after it has been loaded. The correct way of retrieving the class loader would be:

ctClass.getClassPool().getClassLoader

This could be easily done if we added a getClassLoader() method to TypeInfo.

OK, this looks reasonable, as to delay class creation as long as we can.
Like I said, just make sure - perhaps it's already part of javassist code - that there is security enforcement.

[alesj]

"alesj" wrote:

OK, this looks reasonable, as to delay class creation as long as we can.
Like I said, just make sure - perhaps it's already part of javassist code - that there is security enforcement.

- https://jira.jboss.org/jira/browse/JBREFLECT-61