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.
After running test described in issue 121855 one gets following leak: private static org.netbeans.modules.java.navigation.CaretListeningFactory org.netbeans.modules.java.navigation.CaretListeningFactory.INSATNCE-> org.netbeans.modules.java.navigation.CaretListeningFactory@54d7e0-file2JS-> java.util.HashMap@509d47-table-> [Ljava.util.HashMap$Entry;@1b19358-[2]-> java.util.HashMap$Entry@7b859b-value-> org.netbeans.api.java.source.JavaSource@10f433e-classpathInfo-> org.netbeans.api.java.source.ClasspathInfo@197a654-srcClassPath-> org.netbeans.api.java.classpath.ClassPath@bd609f-impl-> org.netbeans.modules.java.j2seproject.classpath.SourcePathImplementation@1ce39a8-projectHelper-> org.netbeans.spi.project.support.ant.AntProjectHelper@1351301-state-> org.netbeans.api.project.ProjectManager$ProjectStateImpl@f89d7c-p-> org.netbeans.modules.java.j2seproject.J2SEProject@1ad37f6
The principal problem here is (I think) that the tasks are not unregistered from the very last JavaSource instance, which is because the event about closing the very last file never comes: issue #100753 (I have copied the metainfo from this issue into that issue). It is a bit surprising that this is the only dump about factories that we have (all factories should be suffering from the same problem) - is only the shortest path from all "similar" paths considered? Another problem is that the CaretListeningFactory holds reference to itself as a static field, which would prevent GC for this class when a module is unloaded, but I do not think this is a huge problem.
Please disregard the part about unloading - the class (and the instance) can be generally unloaded in such a scenario. Sorry for confusion. *** This issue has been marked as a duplicate of 100753 ***
Re: "similar" - yes, only disjunctive leaks are reported. I am not sure why you cannot fix this in CaretListeningFactory.file2JS by pointing to JavaSource using weak references. I disagree about the priority. We need issue 121855 pass, otherwise we cannot enable memory leak tests in commit validation. We either need this one to be fixed or you need to tell us a workaround to prevent it. Also I am not sure why this is considered duplicate of issue 100753. The reference chain is completely different.
Please note that issue #100753 is a P2. I never said this shouldn't be fixed (did I). Workaround should be to open any editor (plain text is enough). Why I think this is a duplicate: CaretListeningFactory (and many other JavaSourceTaskFactories) listen on EditorRegistry (through OpenedEditors class in java/source module). When a visible component is changed, it unregisters tasks from the previous component (if any) and registers them to the new component. The problem is that there is no (reasonable) way to recognize that the last component was closed from the EditorRegistry, so the factories never unregister the tasks from the very last component. While it might be possible (although probably very difficult) to modify OpenedEditors to handle such situation, it seems more appropriate to me to make more or less the same fix into the EditorRegistry for benefit of all users of EditorRegistry (like HintsUI and others).
I do not think that making the reference to JS weak is a good solution: -from API point of view, no client is required to hold the JavaSource instance for the currently opened editor - the factories do currently this (from the API point of view). While a file is opened in the editor, having only one instance of JavaSource is good: it does some caching and it listens on the document. If a JavaSource for the document would disappear, noone would listen on the document and the file wouldn't be reparsed on next change. -currently, the JavaSource itself holds JavaSource instances that have attached tasks, so making JS weak does not ensure that the JavaSource instance is freed (this is an impl. detail, I think). Sorry, but I still think that making the EditorRegistry fire a reasonable event when the very last component is closed would be the most correct solution.