modules introduced a new, more general set of cons...
# generalf
fancy-queen-20734
06/20/2018, 7:18 PMmodules introduced a new, more general set of constraints to allow for that in a more clearly defined way. My understanding is that any given closure of the module DAG cannot have duplicated FQCNs that are visible across module boundaries. It allows duplicated FQCNs as long as they are not within the same closure
w
witty-crayon-22786
06/20/2018, 7:20 PMuh, unless something super fundamental changed, no: it doesn't prevent collisions. it prevents visibility, but not collisions.
witty-crayon-22786
06/20/2018, 7:21 PMthat's what we were pushing for, as that would have actually been useful.
f
fancy-queen-20734
06/20/2018, 7:22 PMYou can’t have two modules in the same closure that export the same packages
fancy-queen-20734
06/20/2018, 7:22 PMso, diamond deps where different deps depend on different versions would require shading
w
witty-crayon-22786
06/20/2018, 7:22 PMright, which is useless
witty-crayon-22786
06/20/2018, 7:24 PM...so yes, i see what you were saying above: "cannot have", in that it will prevent colliding package names. but it's not actually useful.
f
fancy-queen-20734
06/20/2018, 7:26 PMyeah--not for solving the diamond dependency problem
fancy-queen-20734
06/20/2018, 7:27 PMall it does is require that you solve it, it doesn’t say what way is the blessed way to do it
w
witty-crayon-22786
06/20/2018, 7:28 PMthe jvm already required that you solve it. i'd agree that it might be able to fail in a more useful way.
f
fancy-queen-20734
06/20/2018, 7:31 PMoh, I mean before, a tool could try putting both of the conflicting things on the classpath and 🤷 hope it works. In a world where your deps are module-ified, the jvm will fail to start in that case.
4 Views