Lombok in javac messes with enum annotation methods with defaults.

[GoogleCodeExporter]

As soon as lombok.jar is in the classpath when compiling, i get a spooky
behaviour when building with maven:

What steps will reproduce the problem?
1. Have these example classes in src/main/java

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface ComponentPermission {
    String value();

    ActionType type() default ActionType.RENDER;
}

and

public enum ActionType {
    RENDER, ENABLE;
}

right next to each other.

2. Compiles in Eclipse (with or without lombok) and maven.
3. add lombok dependency to pom, and mvn clean compile 
and face:

ComponentPermission.java:[19,40] incompatible types

found   : com.softculture.services.authorization.wicket.ActionType
required: com.softculture.services.authorization.wicket.ActionType

What version of the product are you using? On what operating system?

lombok 0.92, jdk1.6u20/32, eclipse 3.5, maven 2.1.0, maven-compile-plugin
up to 2.3 (does not matter)

problem is reproduceable with simple javac. fails with lombok.jar included
in classpath, passes otherwise.

Original issue reported on code.google.com by google-a...@codesmell.de on 10 May 2010 at 4:08

[GoogleCodeExporter]

This is a javac bug that lombok makes more likely to occur. The fix is even 
more of a headscratcher - write out in 
full the package name of one of them:

ActionType type() default full.package.ActionType.RENDER;

We'll fix this most likely when we tackle resolution as this seems to be 
related to somehow causing javac to 
maintain more than one symbol table.

Original comment by reini...@gmail.com on 12 May 2010 at 11:10

[GoogleCodeExporter]

Issue 127 has been merged into this issue.

Original comment by reini...@gmail.com on 18 Jul 2010 at 5:22

[GoogleCodeExporter]

Original comment by reini...@gmail.com on 25 Jul 2010 at 12:26

• Changed title: Lombok in javac messes with enum annotation methods with defaults.

[GoogleCodeExporter]

This bug is _still_ here and we really should look into fixing it.

Original comment by reini...@gmail.com on 6 Jun 2011 at 7:28

• Changed state: Accepted
• Added labels: Priority-High, Target-Javac
• Removed labels: Priority-Medium

[GoogleCodeExporter]

See: http://netbeans.org/bugzilla/show_bug.cgi?id=193952#c4

I stumbled over it too, adding the CleaningAnnotationProcessor fixed it.
the question is whether this should just be documented or lombok should include 
CleaningAnnotationProcessor and CleaningAnnotationProcessorImpl.

Original comment by pe.f...@googlemail.com on 16 Jun 2011 at 7:59

[GoogleCodeExporter]

Good question. This problem will go away on its own eventually (as javac 1.7 is 
adopted). I'm marginally in favour of adding it to lombok, though lombok cannot 
as far as I can tell ensure it ends up running last. Nevertheless, lombok 
stripping the default attribution out too early is far less likely to actually 
cause a problem than not doing so, hence why I'm in favour.

Roel?

Original comment by reini...@gmail.com on 16 Jun 2011 at 8:07

[GoogleCodeExporter]

So basically the code checks if the compiler contains the bug once, and if so 
it calls the (package) private static method 
JavacProcessingEnvironment.cleanTrees(JCTree[]) with all the methods in all 
compiled classes.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512707 stats that it is 
fixed in java7 and openjdk6 b16.

I'm on the fence.
- It not OUR bug; any processor would trigger the bug
- Then again, we might be the only one, so our users experience this bug
- We want to be the first Annotation Processor, so other processors get access 
to our generated code

I propose to document this behavior, make it googleable, and link to or provide 
a separate jar containing the code from the netbeans site. We might want to 
modify that code to also do a test to see if our environment is actually a 
JavacProcessingEnvironment (instanceof check) and make sure it works in Eclipse 
(as in, does nothing, no Exceptions)

Original comment by r.spilker on 16 Jun 2011 at 8:58

[GoogleCodeExporter]

What would happen if we're not the last processor, but call cleanTrees anyway? 
Will it break other code?

Original comment by r.spilker on 16 Jun 2011 at 8:59

[GoogleCodeExporter]

As Jan Lahoda explicitly said in the netbeans bug report that CAP should 
preferably be run last, I'm guessing it'll break any other AP that runs after 
us that tries to inspect the default value of any @interface.

Original comment by reini...@gmail.com on 16 Jun 2011 at 9:04

[GoogleCodeExporter]

Issue 319 has been merged into this issue.

Original comment by r.spilker on 19 Dec 2011 at 8:58

[GoogleCodeExporter]

Issue 356 has been merged into this issue.

Original comment by askon...@gmail.com on 13 Apr 2012 at 1:47