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.
040908 custom, 1.5.0 b63, under OptimizeIt. After opening and then closing a j2seproject, it is still in memory (after the 15 second timeout). Seems that MCPI.sfbResultListeners holds onto the CompiledSourceForBinaryQuery.Result via SFBQListener.results, and j2seproject's CSFBQ.R holds onto the whole project and thus the ClassPath by which sfbRL is indexed! Need to somehow fix the cache in SFBQListener. Not sure how, but it has to be prepared for the possibility that the SFBQ.R instance has a hard reference to the CP by which the SFBQL is indexed. Somehow need to hold on strongly to both the SFBQ.R and the CP so long as either one is referred to strongly from elsewhere. (You don't want to hold the SFBQ.R weakly, because then it could be collected prematurely and fail to notify you of change events.) I don't know how to do this, actually. I posted a similar puzzle (in a totally different domain) to cdp-perf a few weeks ago, but did not get a reply that I could comprehend.
I don't see a way how to solve this problem in the MergedClassPath. It needs to hold Results to listen on them. It is also impossible for it to find out that the project was closed (since it holds indirectly the project). Probably the most easiest way would be to hold the AntProjectHelper and the PropertyEvaluator weakly in the CompileSourceForBinaryQuery. (Not nice.) Jesse, what do you think?
But then the SFBQ.R implementation is wrong in case the APH & PE get collected. What should it return from getRoots? An empty array? Sounds dangerous to me. Again, I don't know how to solve this (or generally, this class of problems). May simply be impossible in Java.
The only thing I can think of is to have CompiledSourceForBinaryQuery cache Result instances in a WeakHashMap keyed from ClassPath objects of type SOURCE. Of course this has to be done not only in j2seproject, but in any other project types where the SFBQ.R holds a ref back to the project (or, technically, the CP of type SOURCE). A very ugly API to enforce. Or change the API specification of SFBQ to require that the SFBQ impl keep all SFBQ.R instances it makes, and then make MCPI not hold hard refs to them. Perhaps only for project-owned SFBQ's. Not sure whether the same applies to j2seplatform-owned SFBQ's (for platforms and libraries). Again, a very ugly API to enforce.
Agree, another solution is to allow SFBQ.Result.getRoots() to throw an IllegalStateException. This exception can be thrown when APH and PE are collected.
Eek. :-( I am going to try to find someone knowledgeable about weak references here in Burlington to see if the ideal solution is in fact impossible.
Ok
Checking in java/api/src/org/netbeans/spi/java/queries/SourceForBinaryQueryImplementation.java; /cvs/java/api/src/org/netbeans/spi/java/queries/SourceForBinaryQueryImplementation.java,v <-- SourceForBinaryQueryImplementation.java new revision: 1.4; previous revision: 1.3 done Processing log script arguments... More commits to come... Checking in java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/libraries/J2SELibrarySourceForBinaryQuery.java; /cvs/java/j2seplatform/src/org/netbeans/modules/java/j2seplatform/libraries/J2SELibrarySourceForBinaryQuery.java,v <-- J2SELibrarySourceForBinaryQuery.java new revision: 1.10; previous revision: 1.9 done Processing log script arguments... More commits to come... Checking in java/j2seproject/src/org/netbeans/modules/java/j2seproject/queries/CompiledSourceForBinaryQuery.java; /cvs/java/j2seproject/src/org/netbeans/modules/java/j2seproject/queries/CompiledSourceForBinaryQuery.java,v <-- CompiledSourceForBinaryQuery.java new revision: 1.9; previous revision: 1.8 done Processing log script arguments... More commits to come... Checking in java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java; /cvs/java/javacore/src/org/netbeans/modules/javacore/classpath/MergedClassPathImplementation.java,v <-- MergedClassPathImplementation.java new revision: 1.8; previous revision: 1.7 done Processing log script arguments... More commits to come... Checking in java/platform/src/org/netbeans/modules/java/platform/queries/PlatformSourceForBinaryQuery.java; /cvs/java/platform/src/org/netbeans/modules/java/platform/queries/PlatformSourceForBinaryQuery.java,v <-- PlatformSourceForBinaryQuery.java new revision: 1.6; previous revision: 1.5 done Processing log script arguments... More commits to come... Checking in web/project/src/org/netbeans/modules/web/project/queries/CompiledSourceForBinaryQuery.java; /cvs/web/project/src/org/netbeans/modules/web/project/queries/CompiledSourceForBinaryQuery.java,v <-- CompiledSourceForBinaryQuery.java new revision: 1.6; previous revision: 1.5 done Processing log script arguments... More commits to come... Checking in apisupport/project/src/org/netbeans/modules/apisupport/project/SourceForBinaryImpl.java; /cvs/apisupport/project/src/org/netbeans/modules/apisupport/project/SourceForBinaryImpl.java,v <-- SourceForBinaryImpl.java new revision: 1.9; previous revision: 1.8 done
Reorganization of java component