|
|
|
|
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.File directly?
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.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
No. But 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 our private namespace META-INF/debugger for 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:
The default implementation of this API recognizes these properties:
SS_ACTION_STEPOUT
-
When set to Boolean.TRUE, this option is causing step out during smart-stepping
instead of step into. Thus it much faster skips code that is not selected
for debugging, but it may also skip code that should be debugged if it's
called from a source that has debugging disabled.
This is advantageous when the speed is important (e.g. in J2ME).
This property can be set through a map of properties that is passed to
JPDADebugger.attach (), like J2ME_DEBUGGER property.
netbeans.debugger.show_hidden_breakpoints
-
This system property is causing the breakpoints view to show also hidden
breakpoints.
org.netbeans.modules.debugger.jpda.breakpoints.level
-
Logging level for informational messages about breakpoint
submission and hits. They use Level.FINE and Level.FINER levels and
are printed into the NetBeans message log.
netbeans.debugger.start
-
When this system property is set, informational messages about start of
JPDA debugger are printed into standard output (console).
netbeans.debugger.jditrace
-
This system property sets the debug mode of the debuggee virtual machine
via VirtualMachine.setDebugTraceMode() method. See the javadoc
of that method for the description and possible values.
org.netbeans.modules.debugger.jpda.jdievents.level
-
Logging level for informational messages about received JDI events.
They use Level.FINE level and are printed into the NetBeans message log.
netbeans.debugger.smartstepping
-
When this system property is set, informational messages about the smart
stepping process are printed into standard output (console).
netbeans.debugger.noInvokeMethods
-
When this system property is set, methods invocation in debuggee is disabled.
org.netbeans.modules.debugger.jpda.invokeMethod.level
-
Logging level for messages about method invocation.
They use Level.FINE level and are printed into the NetBeans message log.
org.netbeans.modules.debugger.jpda.getValue.level
-
Logging level for messages about variables evaluation.
They use Level.FINE level and are printed into the NetBeans message log.
netbeans.debugger.viewrefresh
-
When this system property is set, informational messages about the tasks
that refresh debugger views are printed into standard output (console).
The value of that property should contain 'w' for watches view, 'l' for
local variables view, 'c' for call stack view, 's' for classes view and
't' for threads view.
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:
debuggerjpda/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 interaction with clipboard.