Details
-
Type:
Bug
-
Status:
Resolved
-
Priority:
Major
-
Resolution: Fixed
-
Affects Version/s: 2.6.1.Release
-
Fix Version/s: 2.8.0.Release
-
Component/s: Compiler Integration
-
Labels:None
-
Number of attachments :
Description
As discussed here:
http://forum.springsource.org/showthread.php?124151-NullPointerException-at-AnnotationVisitor-getConstantExpression()
I have been able to recreate this now (with groovy 1.7) - it can happen when a reference is made into a binary groovy file from an annotation value.
Activity
Andrew Eisenberg
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Fix Version/s | 2.7.1.Release [ 18617 ] | |
| Fix Version/s | 2.7.0.Release [ 18349 ] |
Andrew Eisenberg
made changes -
| Fix Version/s | 2.7.2.Release [ 18821 ] | |
| Fix Version/s | 2.7.1.Release [ 18617 ] |
Andrew Eisenberg
made changes -
| Fix Version/s | 2.8.0.Release [ 18618 ] | |
| Fix Version/s | 2.7.2.Release [ 18821 ] |
Andrew Eisenberg
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
it occurs because 1.7 isn't quite capturing class file constants correctly. For this code
class C { public final static String value = "abc"; }groovy 1.7 produces this decompiled output:
whilst groovy 1.8 produces this decompiled output:
without the classfile capturing the 'constant-ness' we cannot (easily) work out what the value is from a purely static reference. The code in JDTClassNode.fieldBindingToFieldNode cannot cope with this situation. In my testcase I can only get the error on an incremental build (because at that point the class containing the constant only has a binary representation). I can imagine other situations where a reference is made into a jar containing the constant and that would cause all full builds to fail.
I'll spend a few mins thinking about solutions but we may have to just say this kind of thing isn't supported for 1.7.