Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] aspectjtools fail with NPE during maven build

Forget my questions about Java version and AspectJ Maven configuration, I simply forgot to scroll down to the original message. A reproducer project for the new problem would still be helpful, though. We have nothing to work with now, other than textual information. I can only speculate like before about java.lang classes or about you having a problem with duplicate classes on your classpath, maybe the ones from the original JAR and the unpacked and woven ones. I recommend that there is be a separate Maven module taking care of the customer-specific aspect weaving step, depending on the original JAR, unpacking and weaving it, producing a new JAT replacing it, and all the other modules only depending on the woven JAR, not on the original one. Otherwise, it could be like a lottery what the compiler and/or later the application runtime find first on the classpath.
-- 
Alexander Kriegisch
https://scrum-master.de
 

Alexander Kriegisch schrieb am 18.02.2022 10:09 (GMT +07:00):

Great digging, Raimondas! I am impressed that you debugged so deeply into AJC and found org.aspectj.weaver.openarchives. I never knew or used that setting before.


Andy, if you want to reproduce the problem, just run a command like this on JDK 9+ (on 8 you have to add JDK tools.jar to the classpath):

java -Dorg.aspectj.weaver.openarchives=20 -classpath "c:\Program Files\Java\AspectJ\lib\aspectjtools.jar" org.aspectj.tools.ajc.Main -cp "c:\Program Files\Java\AspectJ\lib\aspectjrt.jar" -8 Code.java

You cannot call the ajc.bat or ajc shell scripts directly, because they do not provide any way to pass JVM options. But of course you can set _JAVA_OPTIONS before calling AJC, e.g. like this on Windows:

set _JAVA_OPTIONS="-Dorg.aspectj.weaver.openarchives=20"
ajc -cp "c:\Program Files\Java\AspectJ\lib\aspectjrt.jar" -8 Code.java

Caveat: Do not set the value lower than 20, because then it will default to 1000, see org.eclipse.jdt.internal.compiler.batch.ClasspathJar#ClasspathJar:

private static int maxOpenArchives = 1000;
private final static int MAXOPEN_DEFAULT = 1000;
private static List openArchives = new ArrayList();
// ...
static {
String openarchivesString = getSystemPropertyWithoutSecurityException("org.aspectj.weaver.openarchives",Integer.toString(MAXOPEN_DEFAULT));
maxOpenArchives=Integer.parseInt(openarchivesString);
if (maxOpenArchives<20) maxOpenArchives=1000;
}

Anyway, this will immediately reproduce the problem and create an ajcore dump:

java.lang.NullPointerException: Cannot invoke "java.util.zip.ZipFile.entries()" because "this.zipFile" is null
at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.getModulesDeclaringPackage(ClasspathJmod.java:146)

Andy, would you classify this as a bug or simply as a limitation and setting the system property is the correct way too solve it?


Raimondas, with regard to the other problem, a reproducer would come in handy. It looks like a JMS class-loading problem. At the moment I am not sure why it would fail in 1.9.7 or 1.9.8, but pass in 1.9.4. For debugging this, I think we need more details. Which JDK are you using to build your application? What does the AspectJ Maven configuration look like exactly? 1.9.4 is Java 12, i.e. I can infer you are compiling to a byte code level no higher than that, maybe 11 or even 8. Do you by any chance have any libraries or own code defining classes in the java.lang package? The error message hints at something like that, but I could be wrong.
 

raimondas@xxxxxxxxxx schrieb am 18.02.2022 01:27 (GMT +07:00):

An update if anyone comes across this issue.
I solved the NPE problem by providing -Dorg.aspectj.weaver.openarchives=2000 when running build (which is not documented anywhere by the way, only in aspectjtools source code). It turns out due to big number of classpath entries some of these entries are closed during processing:
 
org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJar
 
// AspectJ Extension
private void ensureOpen() throws IOException { //line 403
    if (zipFile != null) return; // If its not null, the zip is already open
    if (openArchives.size()>=maxOpenArchives) {
        closeSomeArchives(openArchives.size()/10); // Close 10% of those open <-- closed and likely not re-initialized so that zipFile remains null
    }
    zipFile = new ZipFile(file);
    openArchives.add(this);
}
 
However, after fixing this NPE I immediately run into another issue when using aspectjtools 1.9.7 and 1.9.8:
 
[ERROR] Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.14.0:compile (default) on project xxx-app: AJC compiler errors:
[ERROR] error at (no source information available)
[ERROR] C:\Users\....aj:0::0 Type java.lang.Object is indirectly referenced from required .class files but cannot be resolved since the declaring package java.lang exported from module java.base conflicts with a package accessible from module <unnamed>
 
which I solved by using aspectjtools 1.9.4.
 
 
Sent: Tuesday, February 15, 2022 5:23 PM
Subject: Re: [aspectj-users] aspectjtools fail with NPE during maven build
 
What you could do is clone aspectj and build it locally into your maven repo and use it (its pretty straightforward, build a 1.9.9-SNAPSHOT) - with a couple of changes:
- get it to print the zipfilename when the zipfile is attempting to be created, which filename is causing us problems here? That will help us see which of the classpath references is tripping it up.
- cope with unresolved zip file (null check), if you simply ignore the missing zipFile, does it all build just fine and you didn't need anything from that file?
 
My suspicions are a classpath entry that isn't valid coming from somewhere.
 
Andy
 
On Sun, 13 Feb 2022 at 23:49, <raimondas@xxxxxxxxxx> wrote:
So far I was not able to reproduce this issue with the minimal example. The same setup works as expected – aspects build in a separate library and then used as a library in a different module. In a small scale project this works fine.
Please also note that this same unchanged config (as in my prev post) worked perfectly with jdk1.8 and plugin versions: aspectj-maven-plugin v1.8, aspectjtools v1.9.4. The issue happened after upgrade to Java 11 and plugin versions v1.14 and v1.9.7 (keeping previous v1.9.4 for the aspectjtools does not make any difference).
 
I’ve tried with simplified aspectj-maven-plugin config to see if that makes any difference:
<plugin>
                        <groupId>org.codehaus.mojo</groupId>
                        <artifactId>aspectj-maven-plugin</artifactId>
                        <version>1.14</version>
                        <configuration>
                            <complianceLevel>11</complianceLevel>
                            <source>11</source>
                            <target>11</target>
                            <showWeaveInfo>true</showWeaveInfo>
                            <verbose>true</verbose>
                            <aspectLibraries>
                                <aspectLibrary>
                                    <groupId>xxx.xxx.xxx</groupId>
                                    <artifactId>xxx-aspects</artifactId>
                                </aspectLibrary>
                            </aspectLibraries>
                        </configuration>
                        <executions>
                            <execution>
                                <goals>
                                    <goal>compile</goal>
                                </goals>
                            </execution>
                        </executions>
                        <dependencies>
                            <dependency>
                                <groupId>org.aspectj</groupId>
                                <artifactId>aspectjtools</artifactId>
                                <version>1.9.7</version>
                                <scope>compile</scope>
                            </dependency>
                        </dependencies>
                    </plugin>
however, issue is still present.
 
The project where issue happens is a large project with hundreds of modules and >1000 dependency libraries. There is a base platform and client specific customizations on top of it using base platform APIs. Some aspects are defined in the base platform (xxx-aspects) and used as library in the platform customizations for a specific client. The part with
<weaveDirectories>
         <weaveDirectory>${project.build.directory}/classesToWeav</weaveDirectory>
      </weaveDirectories>
simply holds class files that were extracted from the base platform jars during the app build because they need to have client specific aspects applied post compilation and then assembled into deployment.
 
I perfectly understand that without being able to reproduce issue locally it is hard to say anything. To me issue seems more like what I call “curse of the large systems” when factors you wouldn’t even think of may cause unexpected problems. I’d appreciate any hints based on your knowledge about the tools that are being used.
 
 
Sent: Sunday, February 13, 2022 7:00 AM
Subject: Re: [aspectj-users] aspectjtools fail with NPE during maven build
 

It is a bit difficult to debug a Maven POM without any code, especially one with unusual settings like your mix of aspect library, custom includes and custom weave directory. I wonder what those are all for. I never use custom settings like those, even when using aspect libraries.

So please create an MCVE on GitHub. I need something to compile (and run after I fixed the build) in order to reproduce your problem. I have never seen anything like it. Just create a minimal Maven project with just as many modules as needed to reproduce the error. In each module, there can be very simple aspect and application code, I do not need your original source code. But it should be reproducible. Then I can probably help you pinpoint the root cause and maybe suggest an alternative approach or fix something.

 

raimondas@xxxxxxxxxx schrieb am 12.02.2022 19:38 (GMT +07:00):

We are doing migration of our project to Java 11 and got blocked by this aspectjtools fail with NPE during maven build. Context:
1. Java 11 (AdoptOpenJDK jdk-11.0.10.9-hotspot)
2. aspectj-maven-plugin v1.14
3. aspectjtools v1.9.7
4. pom.xml snippet
<plugin>
   <groupId>org.codehaus.mojo</groupId>
   <artifactId>aspectj-maven-plugin</artifactId>
   <version>1.14</version>
   <configuration>
      <complianceLevel>11</complianceLevel>
      <source>11</source>
      <target>11</target>
      <showWeaveInfo>true</showWeaveInfo>
      <verbose>true</verbose>
      <aspectLibraries>
         <aspectLibrary>
            <groupId>xxx.xxx.xxx</groupId>
            <artifactId>xxx-aspects</artifactId>
         </aspectLibrary>
      </aspectLibraries>
      <includes>
         <include>**/*.aj</include>
         <include>**/*.class</include>
      </includes>
      <Xlint>cantFindType=ignore</Xlint>
      <weaveDirectories>
         <weaveDirectory>${project.build.directory}/classesToWeav</weaveDirectory>
      </weaveDirectories>
   </configuration>
   <executions>
      <execution>
         <!-- Compile and weave aspects after all classes compiled by javac -->
         <phase>process-classes</phase>
         <goals>
            <goal>compile</goal>
         </goals>
      </execution>
   </executions>
         <dependencies>
      <dependency>
         <groupId>org.aspectj</groupId>
         <artifactId>aspectjtools</artifactId>
         <version>1.9.7<version>
         <scope>compile</scope>
      </dependency>
   </dependencies>
</plugin>
 
5. Stack trace:
[ERROR] Failed to execute goal org.codehaus.mojo:aspectj-maven-plugin:1.14.0:compile (default) on project xxx: AJC compiler errors:
[ERROR] abort ABORT -- (NullPointerException) null
[ERROR] null
[ERROR] java.lang.NullPointerException
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.getModulesDeclaringPackage(ClasspathJmod.java:146)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathLocation.isPackage(ClasspathLocation.java:184)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.ClasspathJmod.findClass(ClasspathJmod.java:55)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.internalFindClass(FileSystem.java:544)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.findClass(FileSystem.java:464)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.batch.FileSystem.findType(FileSystem.java:617)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.env.IModuleAwareNameEnvironment.findType(IModuleAwareNameEnvironment.java:101)
[ERROR]         at org.aspectj.ajdt.internal.core.builder.StatefulNameEnvironment.findType(StatefulNameEnvironment.java:101)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createPlainPackage(LookupEnvironment.java:1151)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.CompilationUnitScope.buildTypeBindings(CompilationUnitScope.java:136)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.buildTypeBindings(LookupEnvironment.java:487)
[ERROR]         at org.aspectj.ajdt.internal.compiler.lookup.AjLookupEnvironment.buildTypeBindings(AjLookupEnvironment.java:1471)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:870)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:395)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:449)
[ERROR]         at org.aspectj.org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:427)
[ERROR]         at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performCompilation(AjBuildManager.java:1096)
[ERROR]         at org.aspectj.ajdt.internal.core.builder.AjBuildManager.performBuild(AjBuildManager.java:275)
[ERROR]         at org.aspectj.ajdt.internal.core.builder.AjBuildManager.batchBuild(AjBuildManager.java:188)
[ERROR]         at org.aspectj.ajdt.ajc.AjdtCommand.doCommand(AjdtCommand.java:103)
[ERROR]         at org.aspectj.ajdt.ajc.AjdtCommand.runCommand(AjdtCommand.java:47)
[ERROR]         at org.aspectj.tools.ajc.Main.run(Main.java:372)
[ERROR]         at org.aspectj.tools.ajc.Main.runMain(Main.java:250)
[ERROR]         at org.codehaus.mojo.aspectj.AbstractAjcCompiler.execute(AbstractAjcCompiler.java:568)
[ERROR]         at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:137)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:210)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:156)
[ERROR]         at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:148)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:117)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:81)
[ERROR]         at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:56)
[ERROR]         at org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:128)
[ERROR]         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:305)
[ERROR]         at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:192)
[ERROR]         at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:105)
[ERROR]         at org.apache.maven.cli.MavenCli.execute(MavenCli.java:956)
[ERROR]         at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:288)
[ERROR]         at org.apache.maven.cli.MavenCli.main(MavenCli.java:192)
[ERROR]         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[ERROR]         at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[ERROR]         at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[ERROR]         at java.base/java.lang.reflect.Method.invoke(Method.java:566)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415)
[ERROR]         at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)
[ERROR]
 
The problem is that ClasspathJmod objects for JMOD files have zipFile=null
 
image
 
hence this code in ClasspathJmode fails
image
 
After some more patching and debugging I also found that some of ClasspathJar objects throw NPE for the same reason – zipFile is null
 
image
 
I could not find if there is some configuration missing or something else that has to be provided in pom.xml so that aspect plugin finishes successfully. Appreciate any help on this.

Back to the top