Class Loading is an important aspect of las2peer due to its dynamic properties, especially when services should be executed isolated from each other to avoid security issues.
In las2peer, services can be started dynamically, that means that code is loaded at runtime. Also, in modern development processes, new versions are released frequently, and dependent packages may not always keep up with the latest version. So las2peer needs to be able to execute multiple service versions at the same time, and be able to specify dependencies with versions.

To avoid security issues (e.g. when using static classes), each service should be completely isolated from each other, thus having own class instances and not sharing the same data. Since services communicate through service calls provided by the las2peer service API, this is not a problem. At the same time, the same class should not be loaded twice into memory if two services need it.

Another important point is that las2peer is aimed to load classes dynamically from the network, so the implementation of other class sources should be simple.

To sum up, we have the following requirements to our class loader:

• version dependency checks
• transparency: the service developer should not experience any side-effects or limitations
• service isolation: services should not notice the presence of other service instances
• exchangeable class source

las2peer has a class loader that fits these requirements. A summary can be found in the core wiki. The class loader is implemented here.