Support for the Java module system? about roaringbitmap HOT 14 CLOSED

@novoj Thanks.

I must say that I really like PR #657 by @stiemannkj1

It seems to solve a bunch of problems for us. Neat.

from roaringbitmap.

@matteo-catena Please see https://github.com/RoaringBitmap/RoaringBitmap/releases/tag/1.0.0

from roaringbitmap.

I've made a pull request: #656

I'm afraid you'll reject the PR, because I had to get rid of the shims module and upgrade the base java from 8 to 11 to get the module-info.java to work. There may be a way to make this work, but it's beyond my ability to tame the Java module system.

On the other hand - Java 11 is more than 1 year EOL: https://endoflife.date/java ... isn't it a good time to drop its support in RoaringBitmaps? ;)

from roaringbitmap.

Added a PR here which adds module-info.java without dropping Java 8 support: #657

from roaringbitmap.

Pull request invited.

from roaringbitmap.

On the other hand, 33% are still running Java 8 :/ ... according to this presentation: https://docs.google.com/presentation/d/1oMDMQrTiHNkkyL9PnE9A-jLcJBD-ljNwg_JhzvjdzzA/edit#slide=id.g27e04a1c42f_0_0

The figures were taken from: https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem#most-used-java-versions

I'm shooting myself in my own foot, but it's fair to talk about objective numbers.

from roaringbitmap.

@richardstartin Can you comment? What do you think?

Speaking for myself, I am ok with dropping JDK8 support going forward.

from roaringbitmap.

This tweet suggests modules are not actually beneficial or used in production:
https://twitter.com/nevgeniev/status/1704686184302063746?s=46&t=-zo9kVFDyKuN4X1cdtkIrw

from roaringbitmap.

I am also getting a lot of feedback against dropping JDK8.

So I think we will need to keep JDK 8 support.

If modules break JDK 8 support, maybe the problem is with modules themselves?

from roaringbitmap.

It wouldn't be such a problem not to have modular support in RoaringBitmaps, since the Java module systems can work around this using "automatic modules" (see https://dev.java/learn/modules/automatic-module/). The problem is with the shim JAR, which is a separate JAR but uses the same package as the RoaringBitmap JAR. In the Java 9 module system, JARs have to declare different packages in order to be able to export to other modules (or at least that's what I ended up with). So if another library is modularised, RoaringBitmaps can't be used easily and I had to merge RoaringBitmap and shims libraries using the "shade" plugin (see attached pom.xml):

pom.zip

So I'd at least suggest:

a) dropping shims module and integrate it directly into RoaringBitmaps module
b) moving ArraysShim from org.roaringbitmap package to separate one - fe. org.roaringbitmap.shims

Both proposals would allot to use RoaringBitmaps from modularised projects as automatic modules.

from roaringbitmap.

Added a PR here which adds module-info.java without dropping Java 8 support: #657

@stiemannkj1 Will it work? If you exclude module-info.java from the build, will it be present and compiled in the target JAR? I have attached a screenshot of what the internal structure of the modularised JAR looks like:

I have pulled your PR, build it and the module-java.class is missing in the output artifact (if I see correctly).

from roaringbitmap.

@novoj

will it be present and compiled in the target JAR?

It appears to be, when I build it. Have you checked inside the jar produced by the pull request, or are your concerns theoretical?

from roaringbitmap.

I tried it, but in wrong branch. I confirm that in branch ticket-651-add-java-modules-support the module-java.class is present. Sorry for confusion.

from roaringbitmap.

@matteo-catena Please see https://github.com/RoaringBitmap/RoaringBitmap/releases/tag/1.0.0

Thanks, we'll check this out soon!

from roaringbitmap.