If I use "provided" libs on the application server (wildfly), do I gain performance?

Question

imagine the following scenario. I have a Wildfly 8.0.0 application server running with settings default from "factory". On this server I run 4 simple web applications. These applications use some equal libs like:

• Spring Framework;
• Primefaces;
• Spring Security;
• ...

Only that each application packs the libs that it itself uses. Then it packs the spring jars, the primefaces, some Kommons and so on. In fact all applications do this packaging in WEB-INF/lib. Even they pack the same version of Spring from Primefaces...

Now comes some doubts:

1. If I remove the common libs between the applications and put in Wildfly /standalone/lib and set these libs as provided I would get performance in these apps?
2. If there are different versions packaged in the applications, could this be a problem? For example: in one application I put Spring 3.0 and in the other pack Spring 4.0. This can conflict with any of the applications or Wildfly isolates these libs so that one does not interfere with the other?

Answer 1

In theory you can have several benefits when using to share the same libraries among the various applications:

1. Less use of memory, since there will be only one instance of each class in the shared libraries' Classloader, instead of one for each application, in the particular Classloader created for each of them.

2. Shorter boot time, because the application server will not need to load all classes again in the deploy.

3. Lower bandwidth usage and deploy faster, because the package is much smaller. Java applications that I have seen have packages in the 50 to 100MB range, but the application code itself is in general 10% of this size, the rest being only composed of third-party libraries.

4. Best performance, if we consider the greater possibility of using cache that the JVM and the operating system can do since the executed classes are the same.

However, there are also some disadvantages:

1. All applications need to be up-to-date to use the same versions of all Apis, which is often not feasible in a corporate environment.

2. Updating an API needs to be synchronized with updating all applications, which makes it very difficult to administer servers.

3. The assembly of the WAR or EAR package of the applications should be careful, because if an application contains the same dependencies of the shared lib, the "feared" Classloader conflicts may occur, which generate bizarre and difficult to identify errors.

Speaking more specifically about the problems of different classes in different Classloaders, this does not dignify that at all times problems will occur. But if there are two versions of the same library, it may occur that Wildfly loads the classes you wouldn’t want it to load.

This happened a lot with me on Tomcat. The general rule is: the container will always load the version incorrect class!

Another approach that would give a little more flexibility is the use of modules. You could package each framework into a custom module and make your applications depend on those modules. This is an interesting alternative because it allows each application to use only the necessary libs and even different versions of the same framework.

Building modules is a common technique for adding new database drivers, as described at this link.