Maven and Lombok

[Gary Fleming]

I want to annotate some of the fields of a given bean class with the
following annotation:

@Target({FIELD})
@Retention(RUNTIME)
public @interface Process {

Class<? extends ProcessingStrategy> using() default
DefaultImplStrategy.class;

}

Without going into the domain too much, each annotated property needs
to have a ProcessingStrategy defined on it, hence the using() property
on the annotation. That's fine and works the way I'd like it to.

I also want to specify a default implementation of the strategy, to be
used most of the time (the default defined below). This works fine in
Eclipse.

However, when I try to compile this using a regular JDK (invoked
through "maven clean compile") I get the following error:

found : java.lang.Class<DefaultImplStrategy>
required: java.lang.Class<? extends ProcessingStrategy>

Now to the Lombok part: I am far from certain but I think the error is
being caused by Maven doing _something_ wrong when it comes to Lombok.
If I remove all references to Lombok from my project, it compiles
correctly. If I compile directly from javac, it compiles correctly.
It's the combination of Maven and Lombok that seems to not work
correctly.

The maven-compiler-plugin is configured to use javac 1.6.

Has anyone on this list seen this behaviour? Can anyone suggest a fix?

[Reinier Zwitserloot]

I haven't seen that but there is a strange bug in javac itself
regarding symbol linking in annotation declarations which lombok can
aggravate. We HAVE seen this:

public @interface Foo {
SomeEnumType foo() default SomeEnumType.BAR;
}

failing to compile. The workaround for that scenario is to make one of
those 2 fully qualified (add package names). However, that suggests
the problem is that pre-resolution, some symbol tables are being mixed
up. The notion that ProcessingStrategy and DefaultImplStrategy are
related to each other in the type hierarchy is a post-resolution
issue, so I'm not sure these two problems are related. Also, this
particular problem (with the enums, as listed above) is purely a javac
issue and will hence trigger whether you use javac yourself or have
maven invoke it for you.

One thing you can try, though I doubt it'll work, is to fqn (add the
package name) to one or both of those classes. One thing that is
rather confusing to me is that the compiler error turns "Class" into
"java.lang.Class" but failed to do so for DefaultImplStrategy and
ProcessingStrategy, so, definitely try it. Let me know if that doesn't
work.

[Gary Fleming]

Reinier,

Thanks for your help. Fully qualifying the default value solved the
problem, as you suggested.

You said: "One thing that is rather confusing to me is that the

compiler error turns "Class" into "java.lang.Class" but failed to do

so for DefaultImplStrategy and ProcessingStrategy". That's my fault. I
renamed the business-logic heavy strategy names to something more
generic, and in doing so obscured the problem. The error did output
the fully qualified name for DefaultImplStrategy and
ProcessingStrategy. Sorry!

Regards,
Gary