On 04/11/16 10:04, Jochen Theodorou wrote:
> What I see mostly is that all the problems you have now on a per class
> level, you later have on a per module level again... for example needing
> two versions of the same library being active at the same time... and
> the movement away from the static module descriptor to a dynamic module
> loading system with layers and all kinds of shenanigans that will bypass
> these efforts in the end again
Whatever complexity might be involved in managing module layers I think
it's an overstatement to say that the situation will return to the
status quo:
- 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.
- 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.
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.
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?
regards,
Andrew Dinn
-----------
Senior Principal Software Engineer
Red Hat UK Ltd
Registered in England and Wales under Company Registration No. 03798903
Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander
