Hi David, hi all, thanks, David, for your response.
>> 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. > 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? Cheers, Martin -----Original Message----- From: jigsaw-dev [mailto:jigsaw-dev-boun...@openjdk.java.net] On Behalf Of David M. Lloyd Sent: Thursday, October 29, 2015 12:33 PM To: jigsaw-dev@openjdk.java.net Subject: Re: Avoiding same-package conflicts On 10/29/2015 05:59 AM, Martin Lehmann wrote: > Hi all, > > I stumbled across the same "issue". > >> that having multiple versions of the same library isn't a best practice to >> say the least. > 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. We have used our ability to ship multiple modules with the same package names to good effect on more than one occasion. As long as a given module doesn't link the conflicting packages, there is no real problem. Even hypothetical issues involving indirect linkage or passing objects back and forth have never really been a problem for us. > I might have an (artifical?) use case where this might lead to some extra > effort in migration, though: > Let's assume that two libraries D1 and D2 implement the same common API. For > some historical reason, both libraries *ship* the interfaces classes of that > common API. > This won't work (easily) without repackaging jar files (even if the common > API classes would not even differ). > > Example: > A --requires --> B, C > B --requires --> D1 > C --requires --> D2 > D1 and D2 both contain the same interfaces. Even if neither B nor C would > *not* "requires public" D1 / D2, this would not work. > > Too artifical? I actually thought of two logging implementations using & > shipping the common slf4j interface classes. > > 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. 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: * Modules generally use slf4j as a private API to perform their own logging functions * Thus slf4j generally never leaks to a module's exported package set * Thus there's no actual harm in allowing this, and much benefit - especially if B and C (in your example) are not completely under your control (which is inevitable in any nontrivial system) -- - DML
