|
|
The Editor Library 2 module is a set of official APIs and SPIs, designed to replaces the original Editor Library with legacy APIs that are not properly structured and do not conform to the rules implied on the current NB APIs.
The APIs currently offered in Editor Library 2 module include:
The sources for the module are in the Apache Git repositories or in the GitHub repositories.
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:
Yes. The module registers a factory for highlighting layers implemented in
the module.
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 ?
Answer:
No.
org.openide.util.Lookup
or any similar technology to find any components to communicate with? Which ones?
Answer:
The module uses MimeLookup
for various purposes. The Highlighting
SPI looks up factories for highlighing layers registered in MimeLookup under
a mime type of documents that those layer wish to colorify.
Question (lookup-register):
Do you register anything into lookup for other code to find?
Answer:
Yes. There are some implementations of highlighting layers provided by this
module and they are registered in MimeLookup
.
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:
Yes, the Highlighting SPI recognizes the following client properties that can
be set on a JTextComponenet
.
null
,
all layers are used. See
Use case 5.
for more details.
null
,
all layers are used. See
Use case 5.
for more details.
instanceof
,
work with java.lang.Class
, etc.)?
Answer:
No.
Question (exec-threading):
What threading models, if any, does your module adhere to? How the
project behaves with respect to threading?
Answer:
Threading model of the EditorDocument adheres to javax.swing.text.Document interface. There can be multiple reader threads accessing the document simultaneously but only one mutating thread at the time.
All the UI-related tasks adhere to Swing/AWT conventions i.e. they must be performed in EQ thread.
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:
None.
The number of characters in a file multiplied by 2 to respect 2 bytes for each unicode character.
Each line is represented by a line element, which takes up about 96 bytes and a position object occupying another 48 bytes.
Question (perf-limit): Are there any hard-coded or practical limits in the number or size of elements your code can handle? Answer: No explicit limits. Technically, the available memory size is the limit... Question (perf-mem): How much memory does your component consume? Estimate with a relation to the number of windows, etc. Answer: One average source file opened in the editor occupies roughly 500KB. Question (perf-wakeup): Does any piece of your code wake up periodically and do something even when the system is otherwise idle (no user interaction)? Answer: No. Question (perf-progress): Does your module execute any long-running tasks? Answer: Opening a file in the editor can be a long task for large files. Question (perf-huge_dialogs): Does your module contain any dialogs or wizards with a large number of GUI controls such as combo boxes, lists, trees, or text areas? Answer: No. Question (perf-menus): Does your module use dynamically updated context menus, or context-sensitive actions with complicated and slow enablement logic? Answer: No. Question (perf-spi): How the performance of the plugged in code will be enforced? Answer: The infrastructure does not enforce any performance criteria and it's up to modules to perform reasonably. On the other hand each SPI defines its threading and locking model, which should help modules to understand the constraints and impact of their code.