On 04.11.2016 11:50, Andrew Dinn wrote: [...]
- Modules stop you providing two versions of a package in the same layer, a problem for classpath deployment which, as Remi noted, can easily lead to you mixing classes from two different versions of a library.
but sometimes you have to do something similar to that. Usually you then start with classloader magic and have to find your way around "duplicated classes".
What is targeted with modules is that this is done by accident. And frankly, my experience was that those accidental cases have been resolved pretty fast.
- You can indeed use a dynamic module loading system based on layers to introduce versions of the same classes in different layers. However, the unique package ownership requirements means that those layers cannot partake in an ancestor relationship again with the result that duplicate classes cannot then be conflated in the way Remi described.
sure, nobody really needs that on the classpath... except for a poor mans patching.
So, it seems from the above that layers are indeed a structured way to avoid one of the major causes of 'classloader hell' precisely because they detect and reject deployments which introduce these ambiguities in resolution.
"classloader hell" goes far beyond the classpath. The problem is rarely caused by a classloader that loads two versions of the same library with different classes. But happens then more easily if your classloaders suddenly have to become forests. Frankly I do not see how modules will avoid that.
Are you suggesting that modules will not provide this specific benefit or that some other problem will render it of no importance? If the former can you explain why? If the latter can you explain what that other problem is?
well... assume you have an application and it requires the library A, which transitively requires B-1. the application also requires library C, which transitively requires B-2. B-1 and B-2 are not compatible. library A and D leak instances of classes of B-1 and B-2 to the application.
Problem number 1, how to start this if application, A, D, B-1 and B-2 are modules? You don't care that the module system does not allow for this, you have to run it in that configuration and you have to have a way around this. Which means you will have to load modules dynamically in different layers. At this point the benefit already become a burden and is nullified as benefit.
Problem number 2... the layers in which B-1 and B-2 reside in still have their own versions of classes, which are by name equal in B-1 and B-2. If application is actually using classes directly from B-1 or B-2 you get the classloader hell problem, just the same as you would without the module system beyond considering the classpath.
bye Jochen
