ANTLR as a named Java module

[future2r]

Hi there, it is planned to release ANTLR4 as a named module for Java? Currently the ANTLR runtime does not have a "module-info.class". This causes problems when using it with "jlink". As we have Java 15 now and modules can/should be used since Java 9 it would be great to convert ANTLR into a named module too.

Sure, I could inject a "module-info.java" myself with "jdeps --generate-module-info" and "javac --patch-module", but this does not feel right. And it creates new problems if the jar is provided by Maven...

[Thihup]

Are there any updates on this issue?

[ericvergnaud]

Hi,

as you know, ANTLR is Java 8 compatible, when module support was introduced with Java 9. If you can find a way to make it look like a Java 9 module without breaking Java 8 compatibility we’ll definitely look into it.

Eric

Le 15 févr. 2022 à 18:36, Thiago Henrique Hüpner @.***> a écrit :

Are there any updates on this issue?

— Reply to this email directly, view it on GitHub https://github.com/antlr/antlr4/issues/2946#issuecomment-1040572151, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZNQJAUSH3437UWSDDEH53U3KFLHANCNFSM4TA7RUTQ. You are receiving this because you are subscribed to this thread.

[Thihup]

Hi @ericvergnaud! Thanks for the update :)

There are a couple of ways to add the module-info to the project without breaking changes. However, the build itself will require at least Java 11.

With that said,

• You can use the Moditect plugin to inject the module-info: https://github.com/moditect/moditect
• You can run the maven-compiler-plugin twice, one time for compiling the source code and the module-info (compiling as Java 11) and one only for the source-code (compiling as Java 8): https://github.com/piranhacloud/piranha/blob/current/core/servlet-api/pom.xml#L66-L94

This way, the module-info will be at the root of the Jar file. While most of the time it is just fine, some old build tools that don't recognize it yet may break. So maybe you would check the Multi-release Jar (https://openjdk.java.net/jeps/238), and put it in the META-INF/versions/11/module-info.class.

[ericvergnaud]

Hi,

please submit a PR, that's the way we operate :-)

[alexberdnik]

PR submitted, the approach is similar to slf4j's https://github.com/qos-ch/slf4j/blob/master/pom.xml. Decided not to touch the runtime-testsuite module as I'm not sure if it should continue to use java 8. runtime-testsuite also has a bad maven-compiler-plugin configuration - it is not clear which target is in use:

<!-- runtime-testsuite's pom.xml-->
                <configuration>
                    <release>8</release>
                    <source>9</source>
                    <target>9</target>
                </configuration>

[parrt]

I'm not familiar with the module stuff I'm afraid. can we be sure this won't break my simple java 8 world?

[mkoncek]

Hi, I am a Java package maintainer, I have seen a few approaches:

1. Add module-info.java and add a second run of maven-compiler-plugin to compile your module-info.java: https://src.fedoraproject.org/rpms/apiguardian/blob/30ded5f8b6808f385a3f9a5aee471649a49fd7f2/f/apiguardian.spec#_67

2. A simpler approach is to add Atomatic-Module-Name manifest entry, this exports the contents of the whole .jar and does not require you to write your own module-info.java:

<build>
  <plugins>
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <configuration>
        <archive>
          <manifestEntries>
            <Automatic-Module-Name>antlr4.runtime</Automatic-Module-Name>
          </manifestEntries>
        </archive>
      </configuration>
    </plugin>
  </plugins>
</build>

[alexberdnik]

Hi, unfortunately the latter approach is not fully compatible with java module system, e.g. jlink tool would not work.

[mkoncek]

I noticed the linked PR after submitting the comment, that is definitely a way to go.

[kb-1000]

Since bnd is already in use, would it make sense to use it to generate the module-info? https://bnd.bndtools.org/chapters/330-jpms.html This would work if you have to keep compatibility with building ANTLR itself on Java 8 as well.