By sonica
via giallone.blogspot.com
Published: Jan 26 2013 / 09:58
| Core Spring Data | |
| Written by: Oliver Gierke | |
| Featured Refcardz: Top Refcardz: | |
| 150+ Refcardz Available · Get them all | |
By sonica
via giallone.blogspot.com
Published: Jan 26 2013 / 09:58
Comments
MCII replied ago:
A solution looking for a problem.
devdanke replied ago:
This is a bad idea that'll lead to unmaintainable, undebbugable code. If the need for this arrises, it's better to rebuild one version of the class or lib (using something like Maven's Shade pluggin) to put the target class(es) in their own non-conflicting namespace. No normal corporate developer should ever need to delve very deep into classloader black magic.
Paolo Antinori replied ago:
Hi Devdanke, thanks for your comment. I do agree that is not something a developer should use often for the same reasons you remember and the Shade seems to be interesting other option. But since you were citing corporate developers, well, the described technique(technique, not best practice) is what allowed us to not violate the SLA with the provider of the 2 third party libraries since we couldn't obviously alter their code. This is the reason I wanted to describe it as a technique, an option available when do not have better. Anyway the next time I'll try to see if working with something similar to the Shade plugin, could keep us within a supported scenario. And just to add, another option that we considered was JarJar: https://code.google.com/p/jarjar/
henk replied ago:
Not very practical, but an interesting read nevertheless ;)
Voters For This Link (16)
Voters Against This Link (2)