Closed knutwannheden closed 1 year ago
i would think the existing private boolean ignoreClass(Class<?> cls) should call another method in addition to what it does, something like public void ignoreUserClass(Class<?> cls) -- only with a name that doesn't want to make me vomit. (the default of course, does nothing).
That would of course also work. With that design that method could possibly by default check for @Unmetered (a subclass can still include a super call to retain that).
I think my favorite would be if there were some kind of builder API, which can be used to construct a MemoryMeter with the various options. That could then also accept some kind of Filter or Predicate object (working on Class or Object instances). Then I wouldn't need a subclass or access to the private constructor. The only downside is maybe that it makes the API bigger (even more ways to create a MemoryMeter) unless this is an API-breaking change.
yeah that probably would fit how MemoryMeter works now, anyway.
We have refactored how Jamm is designed and for a finer control on which classes and fields should be filtered out it is possible to use the MemoryMeter(MemoryMeterStrategy, FieldAndClassFilter, FieldFilter , boolean, MemoryMeterListener.Factory)
constructor.
I want to use measureDeep() to measure the memory by a given object graph. Now I have some objects in the graph (including any references from these) I want to ignore. With the given API I don't see how I can do that if the classes are 3rd party classes which I cannot annotate with @Unmetered.
If the ignoreClass(Class) could be made protected instead of private I could use that (for full flexibility this would also require making the private constructor public).
Or would it even make sense to have an additional ignoreObject(Object) which by default delegates to ignoreClass()?