module example {
exports x.y.z;
}
import org.immutables.value.Value;
package x.y.z;
@Value.Immutable
public interface T
{
}
Results in:
package org.immutables.value does not exist
... Because the example module doesn't _require_ a module that exports the org.immutables.value package. Of course, we could do this:
module example {
requires static value; // The "static" means "not needed at runtime"
exports x.y.z;
}
... Because Java 9's questionable "automatic modules" feature can take a non-modular jar and treat it as if it contained a module descriptor declaring a module with the same name as the mangled name of the jar file. This has some fairly obvious problems; the name isn't really stable and could quite easily conflict with some other project that just happens to produce a jar named value-*.jar. For this reason, current tools print warnings if you try to explicitly import an automatically-named module like the above.
Short of actually publishing real Java 9 modules of the various Immutables projects (which may be difficult if their dependencies haven't been modularized), the mangled name can be overridden by inserting the following into the MANIFEST.MF of the jar:
Automatic-Module-Name: org.immutables.value
This makes the module act as if it had a module descriptor that declared the module org.immutables.value and exported all of the packages contained within it.
This would assign a stable name to the automatic module (assuming that at some point in the distant future, the project published a real Java 9 module under that name).
This would mean that it could be used from Java 9 modules with:
module example {
require static org.immutables.value;
exports x.y.z;
}
If doing this seems reasonable, I can submit a patch. I'll likely be publishing a real module of immutables-vavr when the next release of vavr is out (because they're intending to either modularize or insert an Automatic-Module-Name entry so that I can explicitly depend on them).
Hm, unfortunately that PR apparently isn't enough. It does fix the problem of not being able to
write require static org.immutables.value, but it seems that the annotation processor just doesn't get executed at all. Silent failure, no sources generated. I'll look into it further.
Some further investigation shows that this might be a Maven issue. It seems that because org.immutables.value became a module, it has to be placed on the _processor module path_ with the --processor-module-path option to javac. If I build the javac command line manually, the annotations get generated correctly.
Hah, it seems that someone else is already ahead of us:
https://stackoverflow.com/questions/46500984/immutables-dont-generate-code-with-java-9-with-modules
@khmarbaise to the rescue once again. 馃憤
@elucash See email. I accidentally pushed the above update to the encode module. On the plus side, it works! I'm waiting for a few other things to be updated before I publish vavr-encodings 0.5.0.
Hey folks! Any progress? We have to give up using immutables because of this...
I was under impression that we have automatic module names specified in jars for some time now, have you tried some of the latest versions like 2.6.3 or 2.7.1 ? If there are still problems, I would kindly ask to reiterate them
Doh... sorry to bother you for no reason. I was missing annotationProcessorPaths on maven-compiler-plugin.
This did the trick:
<plugin>
<artifactId>maven-compiler-plugin</artifactId>
<version>3.8.0</version>
<configuration>
<source>${maven.compiler.source}</source>
<target>${maven.compiler.target}</target>
<annotationProcessorPaths>
<dependency>
<groupId>org.immutables</groupId>
<artifactId>value</artifactId>
<version>2.7.1</version>
</dependency>
</annotationProcessorPaths>
</configuration>
</plugin>
Thank you for sharing it so it's easier to find this important detail about annotationProcessorPaths!
Most helpful comment
Doh... sorry to bother you for no reason. I was missing
annotationProcessorPathsonmaven-compiler-plugin.This did the trick: