Re: [mat-dev] Reworked collection extraction API (bug 442219)

["Tsvetkov, Krum" <krum.tsvetkov@xxxxxxx>]

Hi James,

I'm happy to see you haven't given up, despite me being silent for months after encouraging you to do the contribution.
Sorry for this, I got stuck with lots of other things to do, and I really appreciate that you post again.

In the meanwhile I was able to get the CQ for the collections API change approved. The CQ is based on the patch attached to Bugzilla. I've compared it to the Gerrit change and there are only minor changes in two classes, so I think the CQ is still valid.

I tried using the patched version on a few dumps and the changes seem to work fine.

I suggest we do the detailed discussion in Gerrit.

Let us focus on the API, i.e the classes in org.eclipse.mat.inspections.collectionextract, because this is more difficult to change afterwards.

I don't think it is critical If we have technical errors with one or the other concrete collection. This is much easier to fix with another change, than adapting the API.

Regards,
Krum


-----Original Message-----
From: mat-dev-bounces@xxxxxxxxxxx [mailto:mat-dev-bounces@xxxxxxxxxxx] On Behalf Of James Livingston
Sent: Dienstag, 5. Mai 2015 05:35
To: Memory Analyzer Dev list
Subject: [mat-dev] Reworked collection extraction API (bug 442219)

Hi,

I've finally gotten back to working on the Java EE queries I was doing 9
months ago. As part of that, I need to process java collections
internally within my queries, so started work on moving the logic from
the collections-related queries to some proper API that is usable from
queries.

I've just pushed my prototype API into gerrit at
https://git.eclipse.org/r/#/c/47117/. Although the diff is very large, a
lot of it is moving code around to split up the monolithic classes,
making the existing queries use the new API, and adding support for a
few new collection classes.


The API itself is the six classes under
org.eclipse.mat.inspections.collectionextract.
CollectionExtractor/MapExtractor are the SPI interfaces which know how
to get information out of specific implementation classes.

CollectionExtractionUtils is the initial entry point, usually used by
giving it the IObject for the collection you want to look at.
ExtractedCollection/ExtractedMap are conveniences which bind an
IObject/extractor pair together, and let use them in Java for-each loops
and similar niceties.


I know that I need to add more documentation, and this large a change
would obviously need a lot of testing, but I was wondering if people
could take a look at the API/implementation and see what you think.
Trying to break it on the collections in your heap dumps would also be
useful.

-- 
James "Doc" Livingston <jlivings@xxxxxxxxxx>
JBoss Support Engineering Group


_______________________________________________
mat-dev mailing list
mat-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mat-dev