The default answer to this question is:
These modules are required in project.xml:
java.io.Filedirectly? Answer: No. Question (resources-layer): Does your module provide own layer? Does it create any files or folders in it? What it is trying to communicate by that and with which components? Answer: No. Question (resources-read): Does your module read any resources from layers? For what purpose? Answer: No. Question (resources-mask): Does your module mask/hide/override any resources provided by other modules in their layers? Answer: No. Question (resources-preferences): Does your module uses preferences via Preferences API? Does your module use NbPreferences or or regular JDK Preferences ? Does it read, write or both ? Does it share preferences with other modules ? If so, then why ? WARNING: Question with id="resources-preferences" has not been answered!
org.openide.util.Lookupor any similar technology to find any components to communicate with? Which ones? Answer: Yes. We search for debugger services registered on module layers (System FileSystem). In addition to that we use our own private implementation of lookup pattern. We are searching for instances of various servies defined in *.spi.* packages. The contract is described in JavaDoc. Question (lookup-register): Do you register anything into lookup for other code to find? Answer: We use services registered under
Debuggerfolder in System FileSystem. In addition to that we use our private namespace
META-INF/debuggerfor registration. The contract is described in JavaDoc. Question (lookup-remove): Do you remove entries of other modules from lookup? Answer: No.
System.getProperty) property? On a similar note, is there something interesting that you pass to
java.util.logging.Logger? Or do you observe what others log? Answer: No. Question (exec-component): Is execution of your code influenced by any (string) property of any of your components? Answer: No. Question (exec-ant-tasks): Do you define or register any ant tasks that other can use? Answer: No. Question (exec-classloader): Does your code create its own class loader(s)? Answer: No. Question (exec-reflection): Does your code use Java Reflection to execute other code? Answer: Yes. We search for services registered through standard Lookup under
Debuggerfolder or in our private namespace lookup under
META-INF/debugger. The contract is described in Javadoc. In short: The registered file should contain a list of fully-qualified class names, one per line, of classes implementing the service interface and having default public constructor. It's also possible to append a name of a static method followed by paranthesis, which returns the implementation of the service. That method is then called instead of the default constructor. The method can not take any arguments. If there is a need to remove a service that is provided by some other module, append
'-hidden'after the class or method name. Space and tab characters surrounding each name, as well as blank lines, are ignored. The comment character is
'#'Question (exec-privateaccess): Are you aware of any other parts of the system calling some of your methods by reflection? Answer: No. Question (exec-process): Do you execute an external process from your module? How do you ensure that the result is the same on different platforms? Do you parse output? Do you depend on result code? Answer: No. Question (exec-introspection): Does your module use any kind of runtime type information (
instanceof, work with
java.lang.Class, etc.)? Answer: debuggercore/api does not use introspection. The cases when an object is tested on various types are quite common, but not documented. Question (exec-threading): What threading models, if any, does your module adhere to? How the project behaves with respect to threading? Answer: We use standard Java features - synchronized blocks - to synchronize our code. Question (security-policy): Does your functionality require modifications to the standard policy file? Answer: No. Question (security-grant): Does your code grant additional rights to some other code? Answer: No.
java.awt.datatransfer.Transferable? Answer: No communication with clipboard.