Avoiding same-package conflicts

[David M. Lloyd]

On 10/30/2015 04:12 AM, Martin Lehmann wrote:
> Hi David, hi all,
>
> thanks, David, for your response.

Sure, reply is inline.

>>> Full ACK. Bad practice.
>> I disagree, actually.  I think that this is a completely needless and artificial restriction that arose from implementation decisions, not from a valid requirement.
> You have a point. I don't disagree ;-)
>
>>> So we really need disjunct classes in *all* libraries now? Not even, if the redundant packages are not even exported (right?). Would it work in the "old" classpath?
>> I think that judging by whether something would work in an old classpath is a false test.
>
> I see your point, but:
> On the one hand: Migration will be a big issue. I followed the Monday JavaOne live streams talks (@Alan, @Alex: Thanks for the great talks!) on the topic and understood that stuff should work like before.
> Well, ambitious enough, but if this is indeed the goal, then "did it work in the old classpath?" is definitely something to look at.
> On the other hand - don't get me wrong: I personally prefer to have a clean and  proper solution without (too much) of bad design *just* because backward compatibility.

Sure, but only because you've reversed the logical sense of my argument: 
  I'm saying, don't limit what works under modules to what worked under 
classpath (i.e. using "well it never worked before" as a first-order 
justification for not allowing something to work under modules, or not 
caring that something doesn't work under modules).  You're saying, don't 
break things that previously worked on classpath.  In other words, we're 
not disagreeing, we're making two different points, and I agree with 
yours as well.

>> The whole point of modules is to throw off the restrictions and problems of the classpath, after all.  I think a better test is, "does this make sense?", and to use your slf4j example - it definitely makes sense, because:
>> ...
> Yep, agree.
>
> Btw, I meanwhile thought of a second use case which will *definitely* be needed. Assume to use a third-party library where something is wrong. Fix is not (yet) available, so you need to fix something locally. Up to now a common though bad(?) practice is to patch the library class(es) locally and put it the patched class(es) on the classpath *before* the third-party library (... as a workaround until the real fix is there).
>
> I doubt that I am the only one who ever had the need for such a workaround. If redundant packages are not longer allowed, then I (we?) need a replacement for such a scenario. (Or are I am now really expected to either encapsulate external stuff in different layers and/or to repackage external jar files to guarantee disjunct contents...?) Makes sense?

Under the JBoss Modules system, you typically drop your fixed JAR 
alongside the broken one in the module path, then update your module.xml 
file to point at the new one instead of the old one.  But this only 
works because module descriptors are external to the module in JBoss 
Modules.

-- 
- DML