Compilation in multi-module mode (--module-source-path) not working

[kriegaex]

Using the --module-source-path compiler switch always results in AJC core dumps like ajcore.20220121.082827.213.txt:

java.lang.NullPointerException: Cannot load from object array because "this.modNames" is null
	at org.aspectj.org.eclipse.jdt.internal.compiler.batch.Main.handleModuleSourcepath(Main.java:3741)
	at org.aspectj.ajdt.ajc.BuildArgParser.populateBuildConfig(BuildArgParser.java:203)
	at org.aspectj.ajdt.ajc.BuildArgParser.genBuildConfig(BuildArgParser.java:108)
	at org.aspectj.ajdt.ajc.AjdtCommand.genBuildConfig(AjdtCommand.java:136)
	at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:86)
	at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:47)
	at org.aspectj.tools.ajc.Main.run(Main.java:374)
	at org.aspectj.tools.ajc.Main.runMain(Main.java:253)
	at org.aspectj.tools.ajc.Main.main(Main.java:84)

When testing the latest ECJ 3.28.0 stand-alone in comparison with Javac, I also found out that

• ECJ supports multi-module compilation, so AJC could in principle too,
• but it looks like the neat * module name joker feature for more complicated directory layouts like --module-source-path "./modules/*/src" only works in Javac, not in ECJ. I just created JDT Core bug #578306 for that.

What I also noticed is that for AJC, I always have to put aspectjrt.jar both on the class-path and the module-path, which feels kind of redundant. In Javac, I do not have to do that when compiling @AspectJ aspects. (Of course, that creates unfinished aspects.)

References:

• Project Jigsaw: Module System Quick-Start Guide
• Stack Overflow post describing how to use * patterns in multi-module directory names
• Stack Overflow question asking about AJC --module-source-path support

[kriegaex]

Another thing is that AJC has the very comfortable -sourceroots option, but no counterpart for (multi) modules, such as -modulesourceroots or --module-source-roots. It would be great for users to have an option which unburdens them from having to specify each single file to be compiled, but let the compiler find the files, just like we do it for normal source directories.

See #119.

[aclement]

I think I'd make it separate unless you found codepaths overlapping and could fix the latter whilst doing the former. I still haven't met a person who uses java modules, but I guess they do exist :)

[kriegaex]

If anyone needs something to play with, here is an example project ZIP with two modules, both using AspectJ annotation-based aspects in *.java files (not *.aj). This enables the modules to also be compiled with Javac or ECJ, even though in those cases of course no aspects are woven and the example just runs without AOP.

There is a module org.acme.first and another one org.acme.second, accessing class from an exported package of the first module. It also tries to access non-exported code, which fails as expected unless compiling for Java 8 or using --add-opens.

The example archive also contains two Bash scripts,

• one compiling with AJC in a two-step process, building each module separately directly into corresponding JARs and
• another one compiling with Javac, making use of --module-source-path "./*/src" -m org.acme.first,org.acme.second, i.e. building both modules with a single compiler call. Javac compiles into the bin directory in order not to overwrite any compilation results of the AJC version.

Both scripts also run the application after compilation. Commented out are run commands using --add-opens in order to show how to overcome JMS restrictions when trying to access non-exported packages.

The scripts run in Git Bash on my Windows 10 system. You might need to adjust tool/library paths and path separators (; → :) when trying to run them on your system, maybe on a unix-oid OS. But that should non-trivial changes.