, 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
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
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
scanni
On 7 June 2012 21:11, James Carman wrote:
> On Thu, Jun 7, 2012 at 3:56 AM, sebb 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 use
On Thu, Jun 7, 2012 at 3:56 AM, sebb 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
uberg
>>
>> 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 delegat
> 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
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
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 featu
