Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fully support modular applications by providing module-info.java #284

Open
RobinPlatt opened this issue Aug 14, 2023 · 0 comments
Open

Fully support modular applications by providing module-info.java #284

RobinPlatt opened this issue Aug 14, 2023 · 0 comments

Comments

@RobinPlatt
Copy link

Agrona as-is does not work in java applications which make full use of the java 9 module system -- i.e. applications where the main file is in a module with a module-info.java. This is because agrona does not depend on the jdk.unsupported module, which is necessary in order to access the Unsafe class. An automatic module name is not sufficient to resolve this, by design of the JDK.

We have for some time been using Agrona with an internal build in which the jar is modified and a module-info.java added, which looks like this:

module org.agrona.core {

    requires java.compiler;
    requires java.management;
    requires jdk.unsupported;

    exports org.agrona;
    exports org.agrona.concurrent;
}

Which is great news, it means Agrona can fully support the Java Platform Module System. It could prove useful to others if Agrona provided the module-info.java itself.

Java has multi-version capability of jars so it should be possible to provide the module-info.java without breaking Java 8 compatibility (this is pretty much the main use case of multi-version jars). However, we didn't need to do this, since we only needed the jar to work with JDK 11+. It should be possible, to do the multi-version approach with Gradle: https://stackoverflow.com/questions/47648533/how-to-make-multi-release-jar-files-with-gradle.

Exporting the above two packages was sufficient for our needs. Presumably a number of the other packages are intended as public apis, and should be added, too.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant