commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Honton, Charles" <>
Subject Re: [classscan] Metadata API discussion
Date Wed, 06 Jun 2012 23:49:51 GMT

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


On 6/6/12 2:37 PM, "Mark Struberg" <> wrote:

>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...)
>To unsubscribe, e-mail:
>For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message