Categories
Java

MojoFailureException: Fix Maven’s Compilation Failure:

Today, I faced a compilation failure in Bitbucket pipelines for a simple Java project. The project compiles successfully in the local machine.

The stack trace of the failure was not useful at all:

------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  9.655 s
[INFO] Finished at: 2020-10-14T22:24:42Z
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile (default-cli) on project automation: Compilation failure -> [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.8.1:testCompile (default-cli) on project automation: Compilation failure
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:215)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
Caused by: org.apache.maven.plugin.compiler.CompilationFailureException: Compilation failure
    at org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute (AbstractCompilerMojo.java:1224)
    at org.apache.maven.plugin.compiler.TestCompilerMojo.execute (TestCompilerMojo.java:180)
    at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo (DefaultBuildPluginManager.java:137)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:210)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:156)
    at org.apache.maven.lifecycle.internal.MojoExecutor.execute (MojoExecutor.java:148)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:117)
    at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject (LifecycleModuleBuilder.java:81)
    at org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build (SingleThreadedBuilder.java:56)
    at org.apache.maven.lifecycle.internal.LifecycleStarter.execute (LifecycleStarter.java:128)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
    at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
    at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
    at org.apache.maven.cli.MavenCli.execute (MavenCli.java:957)
    at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:289)
    at org.apache.maven.cli.MavenCli.main (MavenCli.java:193)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
    at jdk.internal.reflect.NativeMethodAccessorImpl.invoke (NativeMethodAccessorImpl.java:62)
    at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke (Method.java:566)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced (Launcher.java:282)
    at org.codehaus.plexus.classworlds.launcher.Launcher.launch (Launcher.java:225)
    at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode (Launcher.java:406)
    at org.codehaus.plexus.classworlds.launcher.Launcher.main (Launcher.java:347)
[ERROR] 
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException

The stack trace doesn’t report any file names or lines numbers. This means the compilation error is not with the source code itself.

Reading the help doc gave me some clue about the problem. After spending some time in investigation, I found that this issue occurred because I was using a custom executable for maven-compiler-plugin that includes a environment variable:

<plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>3.8.1</version>
        <configuration>
          <source>11</source>
          <target>11</target>
          <executable>${env.JAVA_11_HOME}/bin/javac</executable>
          <fork>true</fork>
        </configuration>
</plugin>

Since this environment variable was present in my local system but was not set in Bitbucket pipelines, I was getting the above exception. Setting the environment variable like below in my bitbucket-pipelines.yml file resolved the issue:

image: maven:3.6.3-openjdk-11
pipelines:
  default:
    - step:
        script:
          - JAVA_11_HOME=/usr/local/openjdk-11 mvn -e -X clean compile compiler:testCompile
Categories
IntelliJ

Avoiding Wildcard imports in Java/Kotlin with IntelliJ

What is a wildcard import or a star import?

When you want to import multiple classes from the same package like this:

import com.example.exception.CustomerNotFoundExcetpion
import com.example.exception.ProductNotFoundExcetpion
import com.example.exception.ProductOutOfStockException
import com.example.exception.AdressNotFoundException

Java has an option to combine them into a single line using wildcard imports:

import com.example.exception.*

Is it bad?

Performance-wise, no. Using a wildcard import doesn’t actually import all the classes in the package. When your code is compiled, only the classes used from this package are added to the bytecode. So there is zero performance difference between wildcard import and explicit imports.

Then why should we avoid it?

  • Explicit imports clearly states what external classes the current class is directly using, provided that you don’t leave redundant imports in your code.
  • If there are two classes with the same name from different packages, it can introduce collision when using wildcard imports.
  • When multiple people are working in a project, wildcard imports can create confusion as to which classes are actually imported

Many large Java projects that I have worked with, have a checkstyle rule to disallow wildcard imports for the above reason.

Now that we have understood why explicit imports are better than implicit imports, let’s see how we can make IntelliJ always use explicit imports.

By default, IntelliJ will convert implicit imports into wildcard imports when it sees 5 import statements from the same package.

This setting can however by set to a large value like 99 to prevent the automatic wild card imports.

Goto Preferences -> Editor -> Code Style -> Java (or Kotlin) -> Update the following two values to 99:

  • Class count to use import with ‘*’
  • Names count to use static import

Click ‘Apply’ and close the dialog. Now do ‘Optimize Imports’ again to remove the wildcard imports automatically now and in the future.

More ‘Import’ options can be customized with IntelliJ. Follow this link for more customizations: https://www.jetbrains.com/help/idea/creating-and-optimizing-imports.html

The default Sun & Google’s Checkstyle rules also recommend avoiding star import by throwing this exception:

(imports) AvoidStarImport: Using the '.*' form of import should be avoided

To add this rule to your checkstyle configuration, add this line:

<module name="AvoidStarImport"/>