Open kriegaex opened 2 years ago
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.
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 :)
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,
--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.
Using the
--module-source-path
compiler switch always results in AJC core dumps like ajcore.20220121.082827.213.txt:When testing the latest ECJ 3.28.0 stand-alone in comparison with Javac, I also found out that
*
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:
*
patterns in multi-module directory names--module-source-path
support