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 introduction of native listeners in NetBeans 7.0 (Issue #26230), masterfs module depends on JNA. This is unfortunate situation for NetBeans Platform applications (like Java VisualVM), which cannot use JNA. Usage of JNA should be made optional, since it is not available on all platforms anyway.
Please review masterfs-without-jna-206434 branch: http://hg.netbeans.org/ergonomics/rev/9b72d7313a87 Future step would be to add masterfs.jdk7 module that would handle the listening on plain unices (but not windows) by registering @ position 200. Btw. While at it, I've also added a token to request when relying on FileUtil.toFileObject functionality.
Generally looks good. BTW for the future it is a good idea to use '_' rather than '-' in branch names since '-' can be misparsed as a revset operator (set subtraction). (In reply to comment #1) > Future step would be to add masterfs.jdk7 module That would be great. Of course we would first need to come up with a way to compile against NIO.2 interfaces under JDK 6. > that would handle the > listening on plain unices (but not windows) by registering @ position 200. Why not let it work on Windows too? JDK 7 on Windows supports a native WatchService, and we would prefer not to have to use our own native code. > I've also added a token to request when relying on > FileUtil.toFileObject functionality. Reasonable, though this is used so widely we would never be able to add all the requires statements. Note that it is actually a URLMapper which you are requesting. You could establish a convention that a URLMapper handling some protocol $p should provide "org.openide.filesystems.URLMapper.$p", so that masterfs would provide "org.openide.filesystems.URLMapper.file", but I guess this is less intuitive to use. [JG01] masterfs.linux and the rest are regular modules. Can they be autoloads? I would hope the "recommends" clause in masterfs would suffice, but maybe that only works with regular modules? [JG02] As of module system 7.3 you can use org.openide.modules.os.Linux and org.openide.modules.os.Solaris. [JG03] Consider making pre-7.0-style polling a low-priority implementation of Notifier in its own module, to make it clear that it is normally unused (right?), and could in fact be omitted in a custom app restricted to certain platforms. This could even help satisfy JG01 - you could use "needs" rather than "recommends", knowing that this module could always be enabled even on JDK 6 on OpenVMS or whatever. A basic impl would be simple enough - keep a Map<String,Map<String,Long>> mapping from folder names to timestamps of direct children, and set a 10-second Timer to recheck timestamps. Whether you could make it work exactly like 6.9, i.e. refresh on window activated ("refreshSlow"?), I am unsure (probably depends on an API like that in bug #194147).
(In reply to comment #2) > (In reply to comment #1) > > Future step would be to add masterfs.jdk7 module > > Of course we would first need to come up with a way to > compile against NIO.2 interfaces under JDK 6. I think we will need to do it anyway at least for next version. There is relict of the original double compilation system. Compile everything using JDK6 skipping every module which has javac.source=1.7, then compile again with JDK7 to compile the rest. We can resuscitate this system. > Why not let it work on Windows too? JDK 7 on Windows supports The WatchService was not capable to listen recursively. Our system is primarily used for recursive listeners, so our native implementation is likely to perform better. The same on MacOSX. > > I've also added a token to request when relying on > > FileUtil.toFileObject functionality. > > Reasonable, though this is used so widely we would never be able to add all the > requires statements. Profiler faced that problem when it was executed in JDev environment. > Note that it is actually a URLMapper which you are > requesting. You could establish a convention that a URLMapper handling some > protocol $p should provide "org.openide.filesystems.URLMapper.$p", so that > masterfs would provide "org.openide.filesystems.URLMapper.file", but I guess > this is less intuitive to use. I'll do as reviewers decide. > [JG01] masterfs.linux and the rest are regular modules. Can they be autoloads? > I would hope the "recommends" clause in masterfs would suffice, but maybe that > only works with regular modules? They were supposed to be autoloads: http://hg.netbeans.org/ergonomics/rev/02d92bfbb918 recommends seems to work fine. > [JG02] As of module system 7.3 you can use org.openide.modules.os.Linux and > org.openide.modules.os.Solaris. I see: http://hg.netbeans.org/ergonomics/rev/de4b885257b2 > [JG03] Consider making pre-7.0-style polling a low-priority implementation of > Notifier in its own module, to make it clear that it is normally unused > (right?), and could in fact be omitted in a custom app restricted to certain > platforms. This could even help satisfy JG01 - you could use "needs" rather > than "recommends", knowing that this module could always be enabled even on JDK > 6 on OpenVMS or whatever. Polling is not separated Notifier and in fact it can run in parallel with native notifiers - as soon as a folder is not covered by a native notifier, it is subject to polling check. Useful on Linux, if you run on too old system (OEL4), or you run out of inotify handles. > A basic impl would be simple enough - keep a Map<String,Map<String,Long>> > mapping from folder names to timestamps of direct children, and set a 10-second > Timer to recheck timestamps. Whether you could make it work exactly like 6.9, > i.e. refresh on window activated ("refreshSlow"?), I am unsure (probably > depends on an API like that in bug #194147). Simpler to keep it as it is for now.
(In reply to comment #3) > Compile everything using JDK6 > skipping every module which has javac.source=1.7, then compile again with JDK7 > to compile the rest. We can resuscitate this system. Possible. Nicer would be to have stubs so that everything can be compiled in one pass on JDK 6 (assuming no -source 7). Off topic I suppose. >> JDK 7 on Windows supports > > The WatchService was not capable to listen recursively. Not true; you just need to pass com.sun.nio.file.ExtendedWatchEventModifier.FILE_TREE.
(In reply to comment #4) > > The WatchService was not capable to listen recursively. > > Not true; you just need to pass > com.sun.nio.file.ExtendedWatchEventModifier.FILE_TREE. Not really public API, how have you found this constant? Googling does not seem to help much.
(In reply to comment #5) >> com.sun.nio.file.ExtendedWatchEventModifier.FILE_TREE > > Not really public API No, but not fully private (sun.**) either; should be OK to use if it can be found via reflection, and register does not throw UnsupportedOperationException when passed it. > how have you found this constant? I think it was mentioned in a JRE bug report requesting a public API for this purpose, supported across platforms, rather than the current recommendation to add per-folder listeners.
Merged as ergonomics#912175856cfd