The sources for the module are in the Apache Git repositories or in the GitHub repositories.
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: Yes, files are created for menus, actions, shortcuts, templates, window system layout, settings storage - these are all in standard Open APIs. 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: No. 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 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 comunication with clipboard.