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.
According to issue #32065: It is not reasonable to write data to disk in ReferenceQueue handler. The handler shlould do fast cleanup, not backup of "lost" data. What if the IDE was ended without releasing (and thus saving) the data?
I'm generalizing this task and scheduling to NetBeans 4.0. There are more problems connected to the caching framework that should be addressed in the next release. These are mainly improved testeability and usability of org.netbeans.modules.vcscore.cache.* package, that should re-design the public classes and methods to make implementations easier and better distinguish provided functionality and functionality, that is expected from the implementations. This will also improved testeability. It should be possible to write unit tests. Also performance should be improved. Access to disk cache should be minimized. It must be paid atention not to do more work, that is really necessary. Ideally, performance tests should be written. If a disk cache is corrupted, it should recover automatically (clean the garbage and force refresh to have fresh data). Adding depending issues.
Starting to work on it... Branch "cache_32089" created in vcscore module (with "cache_32089_base" as the base). The re-design will be made in that branch.
Branch cache_32089 was created from prj40_prototype branch. Therefore this branch is unusable in the main trunk (it was not intended to do this in trunk when I started to work on it). But now, the cache redesign is necessary for 3.6 release. Therefore I've created a new branch cache_32089_1 (with base tag cache_32089_1_base) from current trunk in vcscore module. The development of the new caching framework is moved to cache_32089_1 branch.
Unfortunately, the cache redesign is not doable in 3.6 timeframe. We have feature freeze at the end of this week and there are still some UI issues pending. Therefore I'm rescheduling this to promotion D.
Martin, what's your current plan with regard to the cache reimplementation? Do you have an idea if/when it will be available for promo-D? Thanks.
Unfortunately it will most likely not be implemented into promotion-D. We are in a stabilization period and this is considered to be a risky change in this timeframe. It's scheduled for promotion-E. Also API review is in progress (issue #43637).
FYI (copy from issue #43637) I'm working on cache implementation simplification. It uses Map like interface: + void set(FileKey, FileStatus) + FileStatus getCached(FileKey) + void add/removeListener(l) and utility methods: + FileStatus get(FileKey) // may connect to repository + FileStatus getFresh(FileKey) // connects and caches result and utility class IgnoreList + bool isIgnored(FileKey) There is also AbstractFileSystem integration method that allows to trace FileObject's lifetime (and derived FileKey lifetime). + FileReference createFileReference() FileKey is currently FileObjct itself but it seems to lack uniquess and I'll replace it by FileUtil.toFile(fo).getAbsolutePath(). Prototype is being developed in vcscore.turbo package. If it prove successfull it'd affect this issue a lot.
The cache was finally redesigned and implemented according to http://vcscore.netbeans.org/doc/cache/context.html document. Committed to trunk today by Petr Kuzel.