Bug 268027

There is method FileUtil.normalizeFileCached() which is (I guess) supposed to workaround slowness of File.getCanonicalFile().
(More details here - https://netbeans.org/bugzilla/show_bug.cgi?id=65135)

However this cache appears to be cleaned too frequently, for each newly created instance of FileEvent, and negative effect of calls to File.getCanonicalFile() is very significant.

    public class FileEvent extends EventObject {

        public FileEvent(FileObject src, FileObject file, boolean expected, long time) {
            super(src);
            ...
            MIMESupport.freeCaches();
      -->   FileUtil.freeCaches();   <--
        }

        static void freeCaches() {
            normalizedRef.clear();
        }

With such implementation efficiency of cache is significantly reduced, because TTL of the entire cache is around 1 second - 'average' time between file events.

From the other side I see no much sense in cleaning this cache at all (except limiting the total size, what is not there) - some 'input path' will always be normalized to same 'output path'. The exception case may occur on Windows when casing of file name changes ('a'->'A') - this will result in 'wrong' cache entry, however it does not matter on windows - file path are 'case-insensitive' there and 'wrong' cached entry will will work when accessing file system.

However it may happen that caching should be implemented (additionally?) in another method - 

   package org.netbeans.modules.masterfs.filebasedfs;

   public final class FileBasedURLMapper extends URLMapper {
      public final FileObject[] getFileObjects(final URL url) {
        if (!"file".equals(url.getProtocol()))
            return null;
        ...
        try {
            file = FileUtil.normalizeFile(BaseUtilities.toFile(url.toURI()));
        } catch (URISyntaxException e) {


majority of the calls to FileUtil.normalizeFileCached() go through FileBasedURLMapper.getFileObjects(). File paths there are standard absolute path URLs - i.e. mapping between URL and corresponding FileObject is rather static. Additional point of caching on that layer is avoidance of construction of new instances of of FileObject (more performance gain).