In theory you can have several benefits when using to share the same libraries among the various applications:
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.
Shorter boot time, because the application server will not need to load all classes again in the deploy.
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.
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:
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.
Updating an API needs to be synchronized with updating all applications, which makes it very difficult to administer servers.
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.
Just what I needed. So, if theoretically, I establish a well-defined architecture of components in versions between applications in addition to defining a "strict" development, it will tend to facilitate component upgrades afterwards. But this scenario is never perfect. Thank you!
– humungs