Classloaders are the mechanism through which Java locates the definition of a class when the class is referenced. Class definitions are generally provided through a Jar file, but may get loaded at different times. Furthermore, different parts of the system might load jars from different locations, and this process might result in a number of classloaders being used. Classloaders are linked through a hierarchy, and understanding how they are structured in important, as higher class loaders will not be able to see the contents of lower ones. If you tried to do this, you would end up with a ClassNotFound exception, and these types of errors can be difficult to troubleshoot.
In particular, this subject is of the greatest importance when relying on module APIs, or trying to provide your own APIs (code shared across multiple modules). The classloader structures work different for the gateway and designer/client systems.
The gateway maintains a complex classloader structure. This diagram illustrates how they are laid out, and which libraries automatically get loaded at different levels.
This diagram illustrates a few key points:
- All modules have access to the libraries declared in the platform, located under
common, for example.
- Module C, being dependant on Module B, is loaded below B, and therefore has access to its classes (an opc-ua driver is an example of a module that does this).
- Modules B and C cannot access the classes contained in Module A.
However, it is possible for modules to "export" jars in the module manifest, allowing all modules access to them.
The situation in the designer is quite a bit simpler.
All resources are at the same level. This means that modules can access other module classes (though, in practice, this fact is rarely exploited).