NPE when using varargs in mapping method

[filiphr]

From this SO question.

The mapping:

@Mappings({
    @Mapping(source = "code", target = "code")
})
MyResponse mapInformationToErrorData(String code, String... parameters);

Stacktrace:

ErrorMapper.java:[20,8] Internal error in the mapping processor: java.lang.NullPointerException at 
org.mapstruct.ap.internal.util.workarounds.SpecificCompilerWorkarounds.replaceTypeElementIfNecessary(SpecificCompilerWorkarounds.java:112) at 
org.mapstruct.ap.internal.util.Executables.getAllEnclosedAccessors(Executables.java:208) at 
org.mapstruct.ap.internal.model.common.Type.getAllAccessors(Type.java:534) at 
org.mapstruct.ap.internal.model.common.Type.getPropertyReadAccessors(Type.java:397) at 
org.mapstruct.ap.internal.model.BeanMappingMethod$Builder.applyPropertyNameBasedMapping(BeanMappingMethod.java:529) at 
org.mapstruct.ap.internal.model.BeanMappingMethod$Builder.build(BeanMappingMethod.java:145) at 
org.mapstruct.ap.internal.processor.MapperCreationProcessor.getMappingMethods(MapperCreationProcessor.java:373) at 
org.mapstruct.ap.internal.processor.MapperCreationProcessor.getMapper(MapperCreationProcessor.java:152) at 
org.mapstruct.ap.internal.processor.MapperCreationProcessor.process(MapperCreationProcessor.java:123) at 
org.mapstruct.ap.internal.processor.MapperCreationProcessor.process(MapperCreationProcessor.java:80) at 
org.mapstruct.ap.MappingProcessor.process(MappingProcessor.java:280) at 
org.mapstruct.ap.MappingProcessor.processMapperTypeElement(MappingProcessor.java:260) at 
org.mapstruct.ap.MappingProcessor.processMapperElements(MappingProcessor.java:226) at 
org.mapstruct.ap.MappingProcessor.process(MappingProcessor.java:162) at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.callProcessor(JavacProcessingEnvironment.java:794) at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.discoverAndRunProcs(JavacProcessingEnvironment.java:705) at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.access$1800(JavacProcessingEnvironment.java:91) at 
com.sun.tools.javac.processing.JavacProcessingEnvironment$Round.run(JavacProcessingEnvironment.java:1035) at 
com.sun.tools.javac.processing.JavacProcessingEnvironment.doProcessing(JavacProcessingEnvironment.java:1176) at 
com.sun.tools.javac.main.JavaCompiler.processAnnotations(JavaCompiler.java:1170) at 
com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:856) at 
com.sun.tools.javac.main.Main.compile(Main.java:523) at 
com.sun.tools.javac.api.JavacTaskImpl.doCall(JavacTaskImpl.java:129) at 
com.sun.tools.javac.api.JavacTaskImpl.call(JavacTaskImpl.java:138) at 
org.codehaus.plexus.compiler.javac.JavaxToolsCompiler.compileInProcess(JavaxToolsCompiler.java:125) at 
org.codehaus.plexus.compiler.javac.JavacCompiler.performCompile(JavacCompiler.java:171) at 
org.apache.maven.plugin.compiler.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:886) at 
org.apache.maven.plugin.compiler.CompilerMojo.execute(CompilerMojo.java:129) at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132) at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208) at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116) at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:80) at 
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build(SingleThreadedBuilder.java:51) at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:120) at 
org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:355) at 
org.apache.maven.DefaultMaven.execute(DefaultMaven.java:155) at 
org.apache.maven.cli.MavenCli.execute(MavenCli.java:584) at 
org.apache.maven.cli.MavenCli.doMain(MavenCli.java:216) at 
org.apache.maven.cli.MavenCli.main(MavenCli.java:160) at 
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at 
java.lang.reflect.Method.invoke(Method.java:498) at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:415) at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:356)

[chris922]

I started analyzing this issue and I was able to move from the mentioned exception to the next one which looks harder to solve:

The implementation doesn't generate a varargs parameter which is (at least für the eclipse compiler, jdk seems to be ok) required. But I am not able to find in the available API a way to detect if the given TypeMirror is a varargs parameter, it just looks like a regular String[] array.

There is a isVarargs() method available - but not in the public API and thus callable only via reflection (incl. setAccessible(true)) and could be changed in every new release... 😒
JDK: http://www.docjar.com/docs/api/com/sun/tools/javac/code/Type$ArrayType.html#isVarargs
Eclipse: https://github.com/eclipse/eclipse.jdt.core/blob/master/org.eclipse.jdt.core/compiler/org/eclipse/jdt/internal/compiler/ast/Argument.java#L134

Does someone have an idea how we could know that it is a varargs parameter? I guess we need to store this information and when generating the code decide if we should generate [] or ....

[sjaakd]

I did not analyse the issue.. But do we need to know if it is a vargarg? What happens if we treat it as array? Is this the reason of the NPE?

I'm not in favour of using JDK / Eclipse internal methods. We do this, but only if a compiler does not comply to spec (I think we have something for Eclipse). In most cases , newer versions of the compilers will fix these issues. And when we go to java 8 only, it might be possible to remove that again.

[chris922]

The eclipse compiler doesn't allow to override a varargs method using an array... the jdk compiler isn't complaining... 😢

And I am totally with you, try to never use internal methods

[chris922]

Ah, the ExecutableElement of the method has a isVarArgs() method 😃

I checked so many types and the values they had stored in the debugger .. but missed this one the whole time... so now I am one step further.

[filiphr]

When I was reading the emails yesterday evening I was like I have seen isVarArgs somewhere for sure. Good that you found that the ExecutableElement has that :).

[filiphr]

Fixed with PR #1550