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
