See Oracle bug 16450627: INVALIDEXCEPTION :CANNOT START ORG.ECLIPSE.EQUINOX.COMMON .
In the above bug JDev, a product running the Netbinox platform, crashes if its NB caches are corrupted. In the above case, it crashed because the value of 'netbeans.dirs' was different at the time the cache was built and the time the product was ran. The system property 'osgi.install.area', which is equal to the root that every cache entry will be made relative to, is computed by NB as the most common prefix of all entries of 'netbeans.dirs', the caches gave us back the wrong jar locations, and JDev crashed.
The resolution for that bug was to invalidate the caches from the JDev side. But since finding all cases where the cache should be invalidated is a such a ad-hoc, error-prone process, the caching mechanism should be forgiving enough and not crash the entire product. NB caching is an optimization, so--ideally anyway--failure in it should never crash our product, but possibly only run slower.
The puzzler that keeps me busy is: Should the system detect when just the top most directory changes or any change to the list of clusters?
For the JDev case, this is probably the same as addition of new clusters caused the common installation prefix to change. However for NetBeans, this would not be the case. All clusters are usually placed under directory "netbeans" and adding new ones won't change the common installation prefix at all.
The first approach could invalidate just the cache from core.netigso module (however that is unlikely correct, other files, for example containing list of modules have probably changed as well).
The latter approach requires us to store a checksum file (recording information about cache at the time of creation). There currently is such checksum file, but only in user directory and moreover it contains a bit too much information which might now be after installation (like time stamps of .lastModified files in each cluster).