|
From: Chris N. <ch...@si...> - 2003-10-25 19:34:06
|
Mark Pollack wrote: > I think the "side" file approach is also valid...it really tends to be a > matter of taste. I believe the JSR175 committe also debated long and > hard about where to put the attributes and ended up putting it in the > bytecode. > > I'm curious if CGLIB would behave the way suggested. I'm pretty sure it would ;-) > Java already stores > a custom attribute in the bytecode, the 'depreacted' attribute. CGLIB > might strip this out as well. It needs some investigation, I'll look > into it. If it does strip out attributes there are probably implications > for jdk1.5 based code. It's more of a function of the underlying ASM library that CGLIB uses. In its current incarnation it does not pass along attribute info when reading a class, so there is no way for the data to make it into the generated class. You are right that this will have to change in order to support the JDK 1.5 stuff. I've been meaning to get into this issue soon. > The side-file approach does feel better to people, those who typically > dislike anything touching their bytecode and it does mean you don't have > to copy the bcel.jar into ANT_HOME/lib, so it feels more lightweight. When ASM has attribute support added, I think it could be appropriate to have a JSR175-compatible metadata compiler as part of CGLIB, so if you're using Spring you wouldn't have any additional dependencies (currently CGLIB+ASM is less than half the size of BCEL alone). Chris |