Mark, In the BCEL implementation I originally used adapter classes which implemented the appropriate interface and delegated to the BCEL object. Unfortunately, this created a large memory footprint. The BCEL objects are not frugal with memory.
I'm pretty sure we could tease apart the BCEL parts from the caching parts. During that split, we could introduce the scanner SPI. I am a big fan of interfaces. Interfaces at the SPI would allow techniques such as delayed instantiation, perhaps other flexibility that will be useful. On the other hand, we may find each provider re-implement the same Meta information classes. We may wish to provide a default immutable implementation for each meta information interface. You mention that interfaces take a bit more space in memory. Is this because there is an adapter class (implementing the interface) and the delegated final implementor? Or are you pointing out some other memory concern? Chas On 6/6/12 2:37 PM, "Mark Struberg" <strub...@yahoo.de> wrote: >Hi! > >I now did read through the metadata classes of Chas' and Davids impls. > >Both look pretty similar to some degree. A few key differences > >* using AnnotatedElement instead of HasName() makes it possible to >replace most 'old' code which does getAnnotations() etc 1:1 > Imo we should keep this feature. > >* to interface or not to interface, that's the question. > > The actual meta information should be as small as possible. There are >tons of it. > > 1. Currently in Chas' impl there are bcel specific parts in it. Can >those probably be extracted? I think so, or do you see any problems? If >we cannot split then we should keep the interfaces. But remember that >this takes (a bit) more space in mem. > 2. If Interfaces, then impls could point to bcel/asm internal strutures >for storing the data. This would reduce space. But only if bcel/asm would >keep this info anyway. Otherswise it might be better to throw the >bcel/asm stuff away after repackaging to a small meta info holder. > > > >(just to not loose some questions... more to come...) > >LieGrue, >strub > >--------------------------------------------------------------------- >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
