@nitsanw wdyt?

@jponge this can help for Mutiny integration?

That'd be good, although I think in JPMS land you should not append a version but just use org.jctools.core

Can you please remove the spaces/tabs commit?

I'm confused about the value of moving the internal classes to internal, can you elaborate?

@ppkarwasz I appreciate your effort here, but please minimize the contents of the PR to the absolute minimum.
Re-formatting of spaces and tabs, re-ordering of imports, changing unrelated pom files, all of these are not part of the value proposition of your PR. Please revise the PR to contain only the essential changes.

Thanks!

many thanks @nitsanw for the quick review!!

Hi @nitsanw,

I refactored the PR to the bare minimum: the maven-bundle-plugin is reconfigured to export only packages explicitly marked as exported and to generate a module-info.class with a matching OSGI manifest.

I'm confused about the value of moving the internal classes to internal, can you elaborate?

OSGI-wise it doesn't make sense: since the other artifacts in this repo use classes from the org.jctools.core.util package, you need to export the package to everybody.

The advantage appears on the JPMS side: using the exports ... to directive you can prevent third-party modules from using the classes, while at the same time allowing your modules to use them. This is what JUnit 5 did with junit-platform-common (cf. their module-info.java file). Since PaddedAtomicLong must be exported for backward compatibility, it is easier to move the remaining classes.

That'd be good, although I think in JPMS land you should not append a version but just use org.jctools.core

@jponge: I just copied the result of javap module-info.class in the above comment. The compiled module descriptor has a version attribute, but I don't think it can be used for anything practical.

@franz1981 note that a 4.0.2 with a Automatic-Module-Name manifest entry would work for my case in Mutiny

I've checked this PR, the generated module-info looks good:

module org.jctools.core {
    requires java.base;
    requires jdk.unsupported;

    exports org.jctools.maps;
    exports org.jctools.util;
    exports org.jctools.queues;
    exports org.jctools.queues.atomic;
    exports org.jctools.queues.unpadded;
    exports org.jctools.counters;
}

@nitsanw do you think it's ok to roll a new release and get this in?
AFAIK @jponge as others could rely on the presence to dep on JCTools

@franz1981 it's on my todo list :-) I hope to release in the next couple of weeks

@nitsanw If I can help you somehow, just ping me via email (I've sent you an email some time ago, so you'll likely see that one too ;) ) that I will happily help