Please publish an Automatic-Module-Name

[io7m]

Hello.

When using auto to generate code for a modular Java 9 project, you'll get complaints from tools about depending on an automatically-generated module name.

Is there any chance you could add an Automatic-Module-Name entry in the jar manifest in order to provide a stable name upon which other Java 9 projects can depend? I'd suggest:

Automatic-Module-Name: com.google.auto.value

[ronshapiro]

AutoValue is entirely source-level annotations - does that change the picture?

[io7m]

Nope: You're still required to specify a requires static clause in a modular project in order to be able to use the annotations at compile time.

module com.example.mine {
  requires static com.google.auto.value;
}

[heruan]

I'm not able to require the automatic module with the name that should be derived from the JAR file, i.e. auto.service.

I checked with:

$ jar --describe-module --file=$HOME/.m2/repository/com/google/auto/service/auto-service/1.0-rc4/auto-service-1.0-rc4.jar
No module descriptor found. Derived automatic module.

auto.service@1.0-rc4 automatic
requires java.base mandated
provides javax.annotation.processing.Processor with com.google.auto.service.processor.autoserviceprocessor
contains com.google.auto.service
contains com.google.auto.service.processor

but no luck, with requires auto.service I always get:

auto.service cannot be resolved as a module

What am I missing?

[io7m]

@eamonnmcmanus Any movement on this? It's very much a harmless one-line addition to the jar manifest.

[tbroyer]

very much a harmless

See http://blog.joda.org/2018/03/jpms-negative-benefits.html

To emphasise this, just adding something to the MANIFEST.MF file can have an effect on how the project is run and tested. You need to test on both the class-path and module-path.

[Thorn1089]

Stephen Colebourne's opinion aside, Java 12 is out now and 13 is fast approaching. The module system debuted with Java 9. If you don't want to release a modular version of this library you don't have to, but for the rest of us that are trying to use the new module system (and leverage benefits like the stripped down runtimes produced by jlink this is a very straightforward change with a lot of upside.

What is the actual practical concern? Is there a reason to believe that an Automatic-Module-Name entry following the reverse domain convention that the Maven dependency itself uses is not sufficient?

[UkonnRa]

Any update? In Java 14, requires com.google.auto.service; does not work.

wonderland-java ./gradlew build           

> Task :annotations:compileJava FAILED
/home/yukunl/Workspaces/wonderland-java/annotations/src/main/java/module-info.java:3: error: module not found: com.google.auto.service
  requires com.google.auto.service;
                          ^
1 error

FAILURE: Build failed with an exception.

* What went wrong:
Execution failed for task ':annotations:compileJava'.
> Compilation failed; see the compiler error output for details.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

* Get more help at https://help.gradle.org

Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
Use '--warning-mode all' to show the individual deprecation warnings.
See https://docs.gradle.org/6.7/userguide/command_line_interface.html#sec:command_line_warnings

BUILD FAILED in 573ms
3 actionable tasks: 2 executed, 1 up-to-date

[tbroyer]

For auto-service this should be fixed in 1.0-rc7 afaict.

[UkonnRa]

I know what's wrong. When using Gradle with Java module, you should set like this:

  java {
    modularity.inferModulePath.set(true)
    sourceCompatibility = JavaVersion.toVersion("14")
    targetCompatibility = JavaVersion.toVersion("14")
  }

modularity.inferModulePath should be true

[octylFractal]

I'd like to bump this request for auto-common, as it makes it tough to use from an annotation processor that wants to be modular.