Avoid split package scala.collection.generic

[retronym]

Could we move CanCombineFrom and friends to scala.collection.parallel?

This would reduce source compatibility, but give us a better chance at packaging our artifacts as Java 9 modules in the future.

Related discussion:

The real problem is more that after Groovy 2 we started splitting Groovy
into different jars. But for backwards compatibility we didn't change the
packages. So you can find classes in package groovy.util in both the
groovy-core jar and the groovy-xml jar. Those jars would be obvious
candidates for modules but as split packages are not allowed this is not
possible. This doesn't give us many options. I was in favor of breaking
everything, since Jigsaw is a long journey in any case, and leverage that
to have Groovy 3 use different packages. Of course not everybody is happy
with this, because it's a huge issue for all existing libraries that rely
on "old" packages. We would basically break every Groovy program out there.
Both at the source and binary level.

http://jigsaw-dev.1059479.n5.nabble.com/The-split-package-problem-td5714102.html#a5714115

[szeiger]

Yes, they need to be moved before a release. I haven't done anything about them yet because I expect the generic abstractions will be mostly removed in the new collections library anyway.

[SethTisue]

note that scala.collection itself is also split

[SethTisue]

scala.collection.mutable and scala.collection.immutable are split as well

[SethTisue]

We partially “resolved” this by not bothering with OSGi

Also in practice nobody has been bringing up Jigsaw with us in any of the module repos, I guess people either aren't using it or aren't having trouble just exempting our JARs.

The 1.0.0 release is now imminent which means we won't be able to change this around anymore without breaking bincompat, but I think our position is: 🤷‍♂️ — especially since there hasn't been a volunteer to tackle it