Java 9 support

[axelfontaine]

As the GA release is due later this year...

[dbwiddis]

This project is presently impossible to include in a Java 9+ project using JPMS. In order to include it, one has to enter a requires modluename in their module-info file.

This project has not configured any module name, so Java 9+ is falling back to an automatic method of determining the module name, which uses the jar file name, minus the version information. Hyphens are disallowed as characters in module names, so a dot is substituted, creating the automatic module name code.assert.

Unfortunately, assert is a reserved word in Java and thus not possible to include in a module name, so it is impossible to include code-assert as a required dependency. I am forced to either not use modules, or not use code-assert.

Providing module support to Java 9+ without implementing modules yourself is trivial if you use Maven as a build system. Simply add this to your parent pom.xml:

  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-jar-plugin</artifactId>
    <configuration>
      <archive>
        <manifestEntries>
          <Automatic-Module-Name>${autoModuleName}</Automatic-Module-Name>
        </manifestEntries>
      </archive>
    </configuration>
  </plugin>

And then in each of your modules, define that property, e.g., <autoModuleName>guru.nidi.codeassert<autoModuleName>

See this blog post for more details and reasoning why library maintainers should do this.

[dbwiddis]

Any chance you can look into merging #40? Presently the lack of a legal module name is a blocker for using code-assert with JDK 9+.

[nidi3]

Sorry for the long delay.
I merged your PR, thanks for it. There will be a release shortly.

[dbwiddis]

Thanks! Before you release I hope you can test with mvn jar:jar and inspect the META-INF/MANIFEST.MF file to make sure the auto name got added. If not I might need to fix that configuration.

[nidi3]

Yes, it's added.

[nidi3]

released as 0.9.12

[dbwiddis]

FYI, I have been struggling to include code-assert in a modular build. There are two unique issues:

• There is a transitive dependency (via pmd) to javacc which is incompatible:

[ERROR] java.lang.module.FindException: Unable to derive module descriptor for /Users/danielwiddis/.m2/repository/net/java/dev/javacc/javacc/5.0/javacc-5.0.jar
[ERROR] Caused by: java.lang.module.InvalidModuleDescriptorException: jjdoc.class found in top-level directory (unnamed package not allowed in module)

• There is a split package issue from hamcrest library modules.

[ERROR] java.lang.module.ResolutionException: Modules hamcrest.core and org.hamcrest export package org.hamcrest.internal to module junit

I was able to resolve that by changing my own dependency to the hamcrest-core artifact rather than hamcrest.

For the javacc error I've tried using exclusions to tweak things:

		<dependency>
			<groupId>guru.nidi</groupId>
			<artifactId>code-assert</artifactId>
			<version>${code-assert.version}</version>
			<scope>test</scope>
			<exclusions>
				<!-- pmd dependency has class in unnamed package -->
				<exclusion>
					<groupId>net.java.dev.javacc</groupId>
					<artifactId>javacc</artifactId>
				</exclusion>
			</exclusions>
		</dependency>

but that now gives me a split package:

[ERROR] java.lang.module.ResolutionException: Modules pmd.java and pmd.core export package net.sourceforge.pmd.cpd to module saxon

I'm sure there's more I could do playing with exclusions here, but I'm getting out of my depth knowing all the code assert dependencies.

Not really a new problem or new solution but sharing progress in case anyone else is going down this road. I do think updating code assert to the latest version of most dependencies might clean a few things up.