Hi folks, quick reply from vacation :)
@sebb: yes correct. I was just thinking too complicated. We use the interface only for keeping the metainfo, and not in the metainfo itself. So it should itself not blow up the mem. So +1 for the interface. There are 2 important consideration options left: a.) Store the information we get from BCEL/ASM directly in the meta-info instances. b.) Take the information we get from BCEL/ASM and store them e.g. in a SingleLinkedList or array. Which one is more effective also has to do whether BCEL/ASM throw away their information after they pass it to us or if they keep it internally for later reuse. If they store the information anyway, then a.) is better - otherwise we should do b.) LieGrue, strub ----- Original Message ----- > From: "Honton, Charles" <charles_hon...@intuit.com> > To: Commons Developers List <dev@commons.apache.org> > Cc: > Sent: Friday, June 8, 2012 5:47 PM > Subject: Re: [classscan] Metadata API discussion > > 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
