When this project is used in JPMS modular builds, it causes either warnings or errors because it is not declaring a module name. For example, a Gradle build of a project that depends on rhino is producing the following:

> Could not resolve all files for configuration ':project:testRuntimeClasspath'.
   > Failed to transform rhino-1.7.13.jar (org.mozilla:rhino:1.7.13) to match attributes {artifactType=jar, javaModule=true, org.gradle.category=library, org.gradle.libraryelements=jar, org.gradle.status=release, org.gradle.usage=java-runtime}.
      > Execution failed for ExtraModuleInfoTransform: C:\***\.m2\repository\org\mozilla\rhino\1.7.13\rhino-1.7.13.jar.
         > Not a module and no mapping defined: rhino-1.7.13.jar

I'm working around this with the extra-java-module-info Gradle plugin, but it would be handier if this project provided a module name.

One possibility would be to declare an automatic module name for the main rhino jar, see the following blog post for context:

http://branchandbound.net/blog/java/2017/12/automatic-module-name/

The idea would be to add the following to build.gradle, in the section for the jar manifest attributes:

"Automatic-Module-Name": "org.mozilla.rhino",

it could go below the Bundle-* field declarations (i.e. near the line 192 at this moment).

However this project is also providing other jar files, so instead of the automatic name a full JPMS modularization could be performed. That would imply to split the code in a way that two or three modules (with their own module-info files) can be produced, e.g. org.mozilla.rhino.runtime, org.mozilla.rhino.engine and org.mozilla.rhino (although one of the first two could be skipped, leaving only two modules).

If you are curious about what the other projects are doing on JPMS modularization, you may want to check the following blog post:

https://blog.frankel.ch/update-state-java-modularization/

Any thoughts?