Automatic module name, please?

[hrstoyanov]

Can you, pleaase, add automatic module name to the jar manifest, so the library is easy to use in a modular produt?

For example, you could modify the POM.XML to name the jar module net.amygdalum.stringsearchalgorithms (or whatever name you choose) like that:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <version>3.2.0</version>
    <configuration>
        <archive>
            <manifest>
                <addDefaultImplementationEntries>true</addDefaultImplementationEntries>
                <addDefaultSpecificationEntries>true</addDefaultSpecificationEntries>
            </manifest>
            <manifestEntries>
                 <Automatic-Module-Name>net.amygdalum.stringsearchalgorithms</Automatic-Module-Name>
            </manifestEntries>
        </archive>
    </configuration>
</plugin>

Then you can check if the generated jar file has the relevant entry in META-INF/MANIFEST.MF

You can also do this for the other depnency - regexparser

[almondtools]

This is probably needed to use the library with the java module system, right? Can you please explain the benefit of these entries in MANIFEST.MF and what does not work, if these entries are missing?

[hrstoyanov]

If the entries are missing the compiler uses a very brittle algorithm to generate module names from the jar name. You may want to define full modules (module -info.java), but adding an entry to the manifest is a cheap and easy way to modularized the jars.

https://stackoverflow.com/questions/46741907/what-is-an-automatic-module

[hrstoyanov]

Here is the problem I encountered trying to use stringsearchalgorithms in my application that uses Gradle to build it:

With Java 9 modules, the java compiler now has two options from where to load the bytecode - class path (traditional) and module path (new):

javac -classpath <list of classic jars>  --module-path <;list of modularized jars>

Gradle, after it downloads your jars from maven central, needs to decide where to place the jars - on the class or module path, otherwise it is compile error (in my case: error: module not found: stringsearchalgorithms)

The issue is that Gradle will look into your jars, and since it does not find Automatic-Module-Name in the META-INF/MANIFEST.MF, nor it finds a compiled module-info.class proper module definition, it decides to put your jars on the classpath only, hence - the compile time error.

This is a know issue, and in order to override this behavior, one needs to use a very ugly Gradle plugin that effectively transform the plain old jar from maven central into a modularized jar .

But, if you just add the entry in the manifest as outlined above, none of this pain will exist!

[almondtools]

Yet I do not use the java module system myself, so I cannot support errors properly. This is the reason why I am sceptical with your change request.

I expected that the jar would be put on the classpath, so this behavior seems ok to me. Why does gradle search a module stringsearchalgorithms if there is no such module? Couldn't you require the anonymous module (the module that contains everything on the classpath)?

Maybe it is easier to understand for me, if you provide a minimal project where I can test it?

[hrstoyanov]

Adding a Automatic-Module-Name manifest entry will have absolutely no impact if you want to continue using the library as it is rigth now - you can still put it on the classpath and it will be just fine, the manifest entry will be ignored . It could still be used unmodified with Java 9+ on the module path, where the module name will be derived as stringsearchalgorithms - but wouldn't it be better if you decide what exactly the module name should be? (If you rename the jar tomorrow - all user will have broken builds, as this would change the derived module name)?

Anyway, this very minimal and easy request will only help your library users , who:

• use Java 9+ module system for their apps
• AND want to put the jar on the module path instead on the classpath
• AND use Gradle, which makes some hard choices it should not.

[almondtools]

I have released regexparser, can you check whether everything works with regexparser before I release the other artifacts?

<dependency>
    <groupId>net.amygdalum</groupId>
    <artifactId>regexparser</artifactId>
    <version>0.2.4</version>
</dependency>

Maybe it needs some time to get available.

[hrstoyanov]

Confirmed! works nicely, one has to add this to the module definition (you may want to document this)

module my.webapp {
   //...
    requires net.amygdalum.regexparser;

}

Nothing additional needed for Mаven/Gradle, but in Maven central I saw 0.2.5, so I used that instead:

    //Gradle build file
    implementation 'net.amygdalum:regexparser:0.2.5'

Thank you!

[almondtools]

stringsearchalgorithms should be available in version 0.4.4 with automatic module name

[hrstoyanov]

Thank you!