There can be quite a few if you have to have them for every class, interface, annotation, method, field, etc. Then again if you just reuse 1 adapter object all the time it wouldn't be that bad. You would just have to let users know that they cannot maintain references to those objects after scanning is complete. On Jun 7, 2012 8:10 PM, "sebb" <seb...@gmail.com> wrote:
> On 7 June 2012 21:11, James Carman <ja...@carmanconsulting.com> wrote: > > On Thu, Jun 7, 2012 at 3:56 AM, sebb <seb...@gmail.com> wrote: > >> > >> Not sure I follow this. Why would an interface use extra memory? > >> I can see that it might add a bit more to the static size of a class, > >> but why would it add more to each instance of a class that uses it? > >> > > > > It's not the interface itself. It's the fact that you have to have > > more objects loaded into memory when you use the interface-based > > approach. For example, if BCEL has some object that represents a > > class' metadata, then we'll have to put some "adapter" object in front > > of it that implements our metadata API interface and knows how to > > speak BCEL-speak to extract the information. > > Yes, but again, surely there won't be all that many such objects? > > I think some tests should be done of the two approaches before > deciding to abandon the interface-based design. > > > --------------------------------------------------------------------- > > 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 > >
