Potential problem from lack of modular declaration for github-api jar file

[EasyG0ing1]

This project I'm working on, I intend to publish to a public repository at some point ... I ran a Maven verify goal on my project and it came back with this warning:

[WARNING] ******************************************************************************************************************************************************************
[WARNING] * Required filename-based automodules detected: [github-api-1.301.jar]. Please don't publish this project to a public artifact repository! *
[WARNING] ******************************************************************************************************************************************************************

When I looked into the warning, apparently this is considered somewhat serious as it is caused by the library not having a module declaration, where a module declaration remains unchanged in future releases of an artifact where the filename does change. But as it is now, apparently that jar file lacks a module declaration so the module is declared automatically based on the filename.

This can cause problems for projects that depend on other artifacts that also depend on the Git-Hub API when they might depend on two or more and their dependencies on this API have different names. And a project that has such a dependency structure will be unable to run, and fixing it is not an easy proposition... so I guess the rule of thumb is to not publish projects that have dependencies with auto-generated module declarations.

So my question is:

Will you be declaring a module for the Git-Hub API so that this isn't a problem when publishing projects that depend on it?

I realize this means that the API would need to be modularized ... but surely this shouldn't be that much of a bid deal?

Unless my assumptions on this are incorrect and this warning has a more... sinister cause? As in ... something is broken or I'm implementing the API into my project incorrectly?

[bitwiseman]

Here's a the first SO answer I found by searching...
https://stackoverflow.com/questions/46501047/what-does-required-filename-based-automodules-detected-warning-mean

It doesn't offer a clear example in the answer for how to fix this. Many commenters point out that it is a warning.

This page offers some clear instructions, but I haven't had a chance to read if fully to understand the pros/cons.
http://branchandbound.net/blog/java/2017/12/automatic-module-name/

[EasyG0ing1]

@bitwiseman - According to the second article you linked, all that would be required for github-api to be considered an officially named modular library is to include one line in the MANIFEST.MF file. And that one line is:

Automatic-Module-Name: <whatever name you assign>

The idea is that as you continue developing the library, that module name never changes and is provided by the library which satisfies Maven checks and all that.

You can add that line to the library manifest file without even re-compiling it or moving to a different Java version etc.

[EasyG0ing1]

@bitwiseman - Well, I tried to test the claim and added that line to the manifest file and it did indeed cause it to pass the check but then it failed the compile goal stating that it could not find the libraries modules.java file ... so clearly ... it's not as simple as adding that line to the manifest.

[EasyG0ing1]

@bitwiseman OK... so another reversal ... when I added this line to the manifest file in github-api-1.301.jar

Automatic-Module-Name: org.kohsuke.github.api

Then changed my module-info file to match that name ... everything compiles properly and no warning was thrown from Maven.

[bitwiseman]

Submit a PR!

[EasyG0ing1]

@bitwiseman Done!

[EasyG0ing1]

@bitwiseman It should be noted that even though this "fix" allows for compiling and it satisfies the publishing requirement, it still will not build into an executable if the developer uses jlink, because jlink requires dependencies to actually be modular and it specifically errors out when a dependency is implemented and it contains an automatic-module-name.

I'm thinking that at some point, the API should be modularized.

[bitwiseman]

Okay, so what additional work is required?

[EasyG0ing1]

@bitwiseman - No sooner than I posted my last comment I said to myself ... "he's probably gonna ask me to do it" - LOL

So ... I started working on it and should have an answer soon...

I think the first question to answer, is: Will it be acceptable if this API is no longer compatible with Java versions older than version 9? Because once it goes modular, it can't be compiled in any JDK older than version 9.

edit: Actually don't you currently compile the library with JDK 11? - The homepage says it's version 1.8, but as was messing around with the code with module-info, I tried to set my JDK to 9 and IntelliJ said I needed to be at least at JDK 11 when I tried to build the project ... that's where 11 came from anyways.

[bitwiseman]

We compile using Java 11 but we target Java 8. We use Java 11 to create a multi-release jar that has a different limitation for default GitHub connector for Java 11 and later, which is where all this modularization warnings started.

I'd be open to publishing a modularized Java 11 plus only jar for you spy those who care about this, but we need to continue to produce the Java 8 plus compatible jar as well. Sorry.

What you've done is a staffing right direction. Perhaps we can merge that and close this first issue and open another issue regarding full modularization. How does that sound to you?

[EasyG0ing1]

Sounds good to me.