Ales mentioned that it might be worth looking at making the original implementation lazy instead of introducing an extra "wrapper", which sounded like a good idea.
However, thinking about this a bit more I then end up having to hit the classpool which is what I wanted to avoid in the first place. The reason is that when calling i.e. JavassistMethodInfo.getReturnType() we don't know the classpool/loader of the return type, instead we call get() in my previous post with the MethodInfo.getDeclaringClass()'s classloader, which is the only way I can think of to find the classloader. Otherwise we end up possibly using the wrong cache when obtaining the type info. So although we avoid the overhead of b) in my last post we still end up with a)
If I am to go forward with doing it this way, then I think we'll have to look into optimizing the classpools.
Since the introspection implementation performs better than the javassist and bytecode implementations, I tried out something we mentioned on a call before JBoss World which was to use the introspection implementation and to generate the accessors. Unfortunately this also slows down bootup times, probably due to the time taken to generate and then load the class.
|Retrieving data ...|