commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Struberg <strub...@yahoo.de>
Subject Re: [classscan] Metadata API discussion
Date Thu, 07 Jun 2012 04:18:26 GMT
> 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_Honton@intuit.com>
> To: Commons Developers List <dev@commons.apache.org>; Mark Struberg <struberg@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" <struberg@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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message