See: Description
Package | Description |
---|---|
org.netbeans |
The heart of NetBeans Runtime Container. Handles lifecycle of installed modules and OSGi bundles.
Bootstrap classloaders are not paired with a single module, yet they should obey visibility restrictions. The added method allows to check also accesses to resources served by bootstrap classloaders.
This change will hide classes (namely org.objectweb.asm
, but also some core impl classes) that were visible
in Apache NetBeans 9.0 release from NetBeans platform applications.
Special property to disable usage of shared, installation
caches
netbeans.fallback.cache
with special value which can be none
.
Module can be declared as Module Fragment to join other module loader. Fragment classes may ask to be bytecode-patched as superclasses of API classes to preserve compatibility.
Define your Agent-Class to participate in patching other classes.
See netbeans.ignore.dupmodule for details.
NetBeans Module system is optimized to eliminate useless I/O operations on start (as a result the embedded OSGi container is fastest on the planet -- with respect to application start up time). This is achieved by caching information known to have been needed in previous starts and using it rather than obtaining it again from the module JAR files.
There are various caches (like all-layers.dat, all-manifests.dat, all-resources.dat, netigso-bundles, etc. ) provided by the module system or by other subsystems of the application. Together, working in orchestration, they eliminate the need to touch the disk (which is very slow operation especially during morning launch). Btw. there is a test which verifies the caching system really works -- it is recommended for each product built on top of NetBeans Platform to copy and adjust it to verify the caches are really used.
Of course, the caches may get out of date, for example when an external tool modifies the installation layout. How can the system detect whether the caches are valid and still be usable? The only way to verify the caches are 100% correct is to regenerate them and compare whether the cached bits are the same. However that would be terribly slow and defeat the whole purpose of using caches.
As such we have the lastModified API.
Every cluster (as enumerated by netbeans.dirs
and netbeans.home properties)
is supposed to contain such file. Whenever an external tool changes something
inside some cluster, it is supposed to touch the file and change its
timestamp. That will tell the system that caches are invalid
(as their timestamps will become older than newest .lastModified
file).
The caches (as introduced in invalidating caches section) are optimized to reflect the state of previous start. However that means, the very first start runs without them. This may not be a problem (if the start follows immediately after installation), however in multi user environment (when the installation is done by administrator), the first start may be slow.
To mitigate that the system offers support for shared caches. As part of installation, one can also copy certain cache files into the shared location. Those files will then be used on a first start of the system (when the user directory is empty).
To generate the shared cache files start NetBeans with an empty, temporary user directory and then copy the desired files into first cluster directory:
$ netbeans --userdir /tmp/nb -J-Dnetbeans.close=true -J-Dorg.netbeans.core.WindowSystem.show=false $ cd /tmp/nb $ zip -r $INSTALL/$first_netbeans_dirs_dir/var/cache/populate.zip var/cache/netigso $ cp var/cache/* $INSTALL/$first_netbeans_dirs_dir/var/cache $ rm -r /tmp/nb/
The meaning of populate.zip
and list of known cache
files is described here.
Additional modules and subsystems may add new files however. The
ultimate knowledge is available only to those who understand overall
product installation structure.
In case one wants to modify other classes before they get loaded into
the VM, one can register its own
Agent-Class
and then be called whenever another
class is defined. The behavior matches as closely as possible the one
provided by
JDK instrument package. To patch bytecode of other classes
register your class in manifest and in its static agentmain
method
add your own ClassFileTransformer
which will then be consulted whenever new classes are loaded.
# following line should be in manifest of your module Agent-Class: your.pkg.Transformer // this should be your class package your.pkg; public class Transformer implements ClassFileTransformer { public static void agentmain(String args, Instrumentation i) { i.addTransformer(new Transformer()); } public byte[] transform( ClassLoader loader, String className, Class classBeingRedefined, ProtectionDomain protectionDomain, byte[] classfileBuffer ) { // do your transformation } }
The implementation tries to be as complient as possible with the
original JDK's specification, but
some differences are inevitable. For example the classBeingRedefined
parameter in the previous example is always null
as NetBeans runtime container does not
have access to the class instance that is being defined yet.
This is a specific case of Patch Classes use-case. To maintain binary compatibility when removing methods from API classes, the "removed" implementation is actually moved to a special class, which becomes a superclass of the original API class. Such special classes should be separated into a 'compat' module, which is only loaded in presence of old clients.
The compat module should declare it is a fragment of the original API module in its
MANIFEST.MF
OpenIDE-Module-Fragment-Host: orignal.module.codename
which ensures contents of the compat module will be loaded using classloader of the 'fragment host' module. The compat module will not get its own classloader. The special class itself should be marked using PatchFor annotation, which causes it will be patched as superclass and inserted into the inheritance chain.
|
|
|
|
|
|
|
The sources for the module are in the Apache Git repositories or in the GitHub repositories.
XXX no answer for deploy-dependencies
Read more about the implementation in the answers to architecture questions.