In on my MacBook, I get the following counts for running just the unit tests:
Java(TM) SE Runtime Environment (build 1.6.0_29-b11-402-10M3527) Java HotSpot(TM) 64-Bit Server VM (build 20.4-b02-402, mixed mode) Cache: 1 BootstrapClassLoader: 1 WeakConcurrentHashMap: 1 MetaUrlClassLoader: 2 HashWeakReference: 5 FileClassLocation: 5 PrimitiveClass: 9 JarClassLocation: 27 SortedReadOnlySet: 38 BcelEnumProperty: 296 BcelProperty: 740 AnnotationMap$1: 3217 BcelAnnotation: 3417 BcelClass$1: 9251 DeferredMetaClass: 13620 BcelClass$3: 18232 BcelClass$2: 26096 BcelClass: 26774 ArrayMetaType: 33275 ReadOnlySet: 54240 BcelField: 110983 BcelMethod: 231549 BcelParameter: 264572 ClassMetaType: 607104 AnnotationMap: 633878 Regards, chas On 6/7/12 5:27 PM, "James Carman" <jcar...@carmanconsulting.com> wrote: >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 >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
