JBoss Reflection Questions

[flavia.rainone]

Ales,

After taking a look at JBoss Reflection implementation, I have a few questions:

- Why aren't the classes JavassistField, JavassistConstructor, JavassistMethod and JavassistReflectionFactory package-protected? Those names can be easily mistaken with JavassistFieldInfo, JavassistConstructorInfo, etc and they are only used inside their own package.

-What is MutableMethodInfoCommand for?

-At JavassistTypeInfo, what do the TODOS like the one below mean?
//TODO: need to change the use of getType() here
public boolean isCollection()
{
return Collection.class.isAssignableFrom(getType());
}
I see that getType is deprecated. But what is the main idea behind this?

- Are the Javassist Expression interfaces needed? I mean, from http://www.jboss.org/index.html?module=bb&op=viewtopic&t=148169&postdays=0&postorder=asc&start=50,
It is clear they were created for JBoss AOP integration. And I also see that those interfaces were not even implemented. Is it that all, or there is another use case for those? Just trying to define the priority of filling in these blanks.

Plus, I've seen a TODO with JBMICROCONT-132 at ValueConvertor class and this task was resolved in 2006. You left an open question on whether we should remove the support for value creation via constructor with one String parameter. Do you have an answer to this question?

[alesj]

- Why aren't the classes JavassistField, JavassistConstructor, JavassistMethod and JavassistReflectionFactory package-protected? Those names can be easily mistaken with JavassistFieldInfo, JavassistConstructorInfo, etc and they are only used inside their own package.

Looking at them now, I guess they could be moved to pckg protected.
But it was Adrian who did this piece.
I guess it's his call to try to stop you of doing this. :-)

-What is MutableMethodInfoCommand for?

Looking at the one comment

 /**
 * TODO: something similar to CtBehavior.instrument(...)
 * /
 void executeCommand(MutableMethodInfoCommand mmc);

This is something Stale had in mind, but it looks like he never finished.

-At JavassistTypeInfo, what do the TODOS like the one below mean?
//TODO: need to change the use of getType() here
public boolean isCollection()
{
return Collection.class.isAssignableFrom(getType());
}
I see that getType is deprecated. But what is the main idea behind this?

This TODO was meant in the sense of "try not to use getType".

Afair, the idea is to be able to handle all (ok, almost all) of the Reflect use cases w/o the need of getType.
Currently this is not exactly the case.
I hope Adrian can shed some more light on this subject.

- Are the Javassist Expression interfaces needed? I mean, from http://www.jboss.org/index.html?module=bb&op=viewtopic&t=148169&postdays=0&postorder=asc&start=50,
It is clear they were created for JBoss AOP integration. And I also see that those interfaces were not even implemented. Is it that all, or there is another use case for those? Just trying to define the priority of filling in these blanks.

Yes, this was mainly to do proper Reflect abstraction for AOP.
e.g. not really relying on Javassist details

But yeah, this is not a priority.
Although it would be nice to finish this once. ;-)

Plus, I've seen a TODO with JBMICROCONT-132 at ValueConvertor class and this task was resolved in 2006. You left an open question on whether we should remove the support for value creation via constructor with one String parameter. Do you have an answer to this question?

I know Adrian and me once had this discussion.
I'll try to find it, but I think you can leave it for now.
It's been serving us OK so far ... :-)

[flavia.rainone]

"alesj" wrote:
But yeah, this is not a priority.
Although it would be nice to finish this once. ;-)

I created a Jira issue for this one:
https://jira.jboss.org/jira/browse/JBREFLECT-54