Cannot use Fastutil 8.5.4 in modular application

[iTitus]

Cannot use Fastutil 8.5.4 in modular application. Errors:

the unnamed module reads package it.unimi.dsi.fastutil.shorts from both it.unimi.dsi.fastutil and it.unimi.dsi.fastutil.extra
...
module it.unimi.dsi.fastutil.core reads package it.unimi.dsi.fastutil.booleans from both it.unimi.dsi.fastutil.core and it.unimi.dsi.fastutil.extra

I think the problem is that different modules cannot provide the same package.

[vigna]

Sigh. Why was I sure that was gonna happen?

Apparently, I did everything in the right way, using Require-Bundle to split packages across bundles. I'm now finding notes in stackexchange and other places about the fact that bnd does not support Require-Bundle. I'm still investigating—if you can help with this, or you know someone who can help, that'd be great.

[iTitus]

Sadly I don't know how. Is it even necessary to have the package in all jars? if its an internal helper maybe move it into a separate package or another libary?

[dsubelman]

I'm having the same issue. I agree with @iTitus, my best guess is also that the three new jars share common packages.

Another related issue that I found is that Fastutil 8.5.4 fails when you include other dependencies that also depend on Fastutil (i.e. Tablesaw) and you manage the dependency convergence (i.e. Maven Enforcer Plugin).

I think the reason here is not only that jars share common packages, but also that fastutil.jar (the jar with the remaining data structures) have the same name as the previous single jar in Fastutil 8.5.2 .

A possible solution for the second issue could be to rename fastutil.jar to fastutil-rest.jar.

[vigna]

I've read in a Manning book that probably the correct thing to do would be to have a façade fastutil.jar with dependency on the other three jars.

On the other hand I'm a bit confused because elsewhere they say that you cannot import a package split between jars—you have to require the bundle, rather than import a package. What if you do a Require-Bundle it.unimi.dsi.fastutil instead of an import?

[vigna]

A possibility is to do a complete rollback and put back the jars together. Then when we move to Java 9 I've read you can split packages. But it would be nice to have a clean OSGi solution. I've asked on StackOverflow for suggestions without success.

[A248]

Uhh, just to make sure everyone is on the same page - I think this issue was raised about JPMS modules, not OSGI bundles. Or maybe I'm missing something.

It might be the case that there's a problem with OSGI too, but the error message above definitely reads like a JPMS (Jigsaw) issue.

[iTitus]

OSGi is not the concern here. We should rather care about the module system, as modern JVMs depend on it

[vigna]

I think this is probably true as the new release does not work with JGraphT, which uses JPMS but not OSGi. Up to now the JPMS infrastructure was happy with the OSGi data. Maybe I should leave the JAR separation for a Java 9-only release.

[vigna]

Commit c8050c0f23f1a43 changes the way I distributed fastutil. There will be a traditional fastutil.jar, and a fastutil-core.jar with the basic classes. They have overlapping classes and no dependency between them. If you happen to have both on your classpath, you should exclude fastutil-core.jar. Please let me know if this works for you.

[iTitus]

Will you create a new build on Maven or shall I try to self-build?

[vigna]

If you can try, that would be great a a test. However, since your are using the full jar I expect everything to work. It's the core package that should be tested instead...

[dsubelman]

Thanks for the changing the way fastutil is distributed. I tested the full jar and as you said it worked. Haven't test core though.

[vigna]

Ok, thanks. Other people are testing the core jar and then I'll distribute 8.5.5.