Bug 206434 - masterfs depends on JNA
masterfs depends on JNA
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
7.0
All All
: P1 (vote)
: 7.2
Assigned To: Jaroslav Tulach
issues@platform
: API_REVIEW_FAST
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-12-15 11:04 UTC by Tomas Hurka
Modified: 2011-12-31 16:01 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Hurka 2011-12-15 11:04:16 UTC
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.
Comment 1 Jaroslav Tulach 2011-12-15 13:59:59 UTC
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.
Comment 2 Jesse Glick 2011-12-15 16:35:18 UTC
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).
Comment 3 Jaroslav Tulach 2011-12-15 17:50:20 UTC
(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.
Comment 4 Jesse Glick 2011-12-15 18:23:08 UTC
(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.
Comment 5 Jaroslav Tulach 2011-12-25 15:29:14 UTC
(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.
Comment 6 Jesse Glick 2011-12-27 18:11:01 UTC
(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.
Comment 7 Jaroslav Tulach 2011-12-31 16:01:18 UTC
Merged as ergonomics#912175856cfd


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2012, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo