This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I wonder why my ResourceBundle instances are not displayed on the results list when I'm chosing "Analyzing memory usage|Record object creation only|Track every 1 allocation". My bundles are classes named like the following: tld.domain.project.resources.ProjectResources tld.domain.project.resources.ProjectResources_en and the like. Don't know if its a) a bug or b) a decision (to filter some stuff implicitly). It's not really critical, but raises the question "What else might be missing?". So, if b) is true, I'd like to know about the profiler's strategy to filter.
For memory profiling, no classes are filtered out. This sounds like a bug of some sort. Are you sure that the instances of those classes are created? Are the resource bundle classes on the application classpath? Perhaps if there was a small test app that the problem would be reproducible with it would be much easier for us to hunt down the problem.
Yes and Yes. Please try the test app attached (note: the Res.Bundle classes are located in a subpackage, but I don't think that's critical). In the LiveResult list I usually filter for e. g. "tld.domain.project", but none of my bundle instances appears. Looking for "java.util.Locale", you'll see the growing "Allocated Instances", but neither "java.util.ResourceBundle" nor "java.util.ListResourceBundle" instances are shown (but: some inner classes of Res.Bundle like "java.util.ResourceBundle$1" etc.).
Created attachment 26233 [details] Test app (without package path!)
Created attachment 26234 [details] Test app (without package path!)
Sorry, duplicated the attachment by mistake.
The reason for this is that the resource bundle instances are allocated dynamically via the Class.newInstance call, which th ememory profiling currently does not track. The other issue that you filed covers the root cause for this, marking this one as a duplicate. *** This issue has been marked as a duplicate of 62476 ***
Verification of old issues.
Closing old issues
Reverting to original Target Milestone value changed by mistake. Sorry for inconvenience.