> 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? It's not much actually. Merely 80 bytes + fully qualified class name length. But we have 100.000s of instances. That might sum up. We need to trace it finally. Otherwise +1 for interfaces.
LieGrue, strub ----- Original Message ----- > From: "Honton, Charles" <charles_hon...@intuit.com> > To: Commons Developers List <dev@commons.apache.org>; Mark Struberg > <strub...@yahoo.de> > Cc: > Sent: Thursday, June 7, 2012 1:49 AM > Subject: Re: [classscan] Metadata API discussion > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
