To maintain binary compatibility, method implementations may be injected at runtime, in a form of a superclass in the class' inheritance hierarchy. Modules compiled against older version of APIs which contains MethodReferences to methods removed from the oficial APIs will be then linked according to JVM Resolution algorithm to a matching method present in the superclass of the referenced type.
Annotations are used to instruct the ClassLoader to make transformations to the API classes. PatchFor causes the annotated class to be injected as a superclass of the API class identified by the annotation's value. ConstructorDelegate marks a method, which is called as constructor implementation in the case that it is necessary to preserve a constructor for binary compatibility.Question (arch-time): What are the time estimates of the work? WARNING: Question with id="arch-time" has not been answered! Question (arch-quality): How will the quality of your code be tested and how are future regressions going to be prevented? WARNING: Question with id="arch-quality" has not been answered! Question (arch-where): Where one can find sources for your module? WARNING: Question with id="arch-where" has not been answered!
The default answer to this question is:
These modules are required in project.xml:
The entire API is one public package. ModulesAPI
The implementation is in another package and is not considered
public, though it is made available to
apisupport as these special modules deal directly with
the module system at a deeper level than the API provides for.
Yes, module JARs and associated resource JARs must be real files. They are loaded as defined by module enablement XML files.
Module enablement XML files are loaded via Filesystems. The public
API (partially) specifies them only in these terms.
autoupdate uses Filesystems to manipulate them when
necessary, though it relies on some additional
implementation-specific knowledge of their format (which is fairly
stable, especially since changes are limited by compatibility
constraints on old user directories). The NetBeans build scripts use
some additional implementation knowledge to pregenerate suitable XML
files for modules included in the application distribution.
or any similar technology to find any components to communicate with? Which ones?
instances are queried and used
Do you register anything into lookup for other code to find?
TestModuleDeployer (from META-INF), used by apisupport
InstalledFileLocator (from META-INF), used by its public default method
ModuleInfo, via a custom lookup insertion (specified in API)
ClassLoader, via a custom lookup insertion (used broadly)
On a similar note, is there something interesting that you
java.util.logging.Logger? Or do you observe
what others log?
NetBeans installation directory.
Additional installation component directories.
Classpath appended to the system class loader.
Used for automated testing infrastructure.
May be used to prepend items to the same class loader as is used
for openide.jar and core.jar, similarly
to JARs found in lib/patches/.
By default true, may be turned off to disable manifest caching.
Patch directories or JARs to add to the class loader for a module,
If true, all module classes are forcibly loaded at startup, to help
detect possible linkage errors.
Disables automatic module dependency upgrades.
If set to 0, enables logging for the module system.
Disabled automatic transitive class loader dependencies for old modules.
Avoids text messaging (other than
ErrorManager logging) to the console
from the module system.
Suppresses checks to ensure that module section classes are actually loaded
from the module itself.
Avoids using GUI when user-visible error conditions occur.
Name of class from core.jar which will handle most of the
startup sequence; by default, org.netbeans.core.Main.
Suppress security checks in the VM, even from "untrusted" code.
Prints messages when resources or classes are loaded from JARs.
Used to control the XML layer cache mechanism. Value may be a
fully-qualified class name to load as a manager (implement
- to disable caching and always parse the XML
layers directly. Current default is to use a binary cache
WARNING: Question with id="exec-introspection" has not been answered!
What threading models, if any, does your module adhere to? How the
project behaves with respect to threading?
WARNING: Question with id="exec-threading" has not been answered!
Does your functionality require modifications to the standard policy file?
WARNING: Question with id="security-policy" has not been answered!
Does your code grant additional rights to some other code?
WARNING: Question with id="security-grant" has not been answered!
is a Swing-safe bean that serves as a nonblocking wrapper for all module system
modifications and is used e.g. in the Modules node.
Does your module contain any dialogs or wizards with a large number of
GUI controls such as combo boxes, lists, trees, or text areas?
No. Occasionally small dialogs only.
Does your module use dynamically updated context menus, or
context-sensitive actions with complicated and slow enablement logic?
How the performance of the plugged in code will be enforced?
WARNING: Question with id="perf-spi" has not been answered!