[ https://issues.apache.org/jira/browse/GROOVY-8383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Paul King updated GROOVY-8383: ------------------------------ Description: {code} @groovy.transform.CompileStatic def method() { Long wrapper = 2L long prim = 2L } method() {code} gives: {noformat} java.lang.NoSuchFieldError: $const$0 {noformat} swapping the second {{2L}} with {{3L}} or {{wrapper}} side steps the problem. The primitive and wrapper constants are being deemed the same but the types won't match ({{J}} vs {{Ljava/lang/Long;}}). Other types are also affected but seemingly not int or double. Swapping the order has no affect. I assume the code in OptimizerVisitor#setConstField is not @CS friendly. That code has an early return for Integer and Double. In addition, the current implementation has a limitation if the user uses field names similar to what the visitor generates, e.g. {{$const$0}}. A similar error will occur if such a field exists but has the wrong type: {code} class Bar { private String $const$0 = 'bar' def method2() { Long wrapper3 = 20L } } new Bar().method2() // => NoSuchFieldError {code} was: {code} @groovy.transform.CompileStatic def method() { Long wrapper = 2L long prim = 2L } method() {code} gives: {noformat} java.lang.NoSuchFieldError: $const$0 {noformat} swapping the second {{2L}} with {{3L}} or {{wrapper}} side steps the problem. The primitive and wrapper constants are being deemed the same but the types won't match ({{J}} vs {{Ljava/lang/Long;}}). Other types are also affected but seemingly not int or double. Swapping the order has no affect. I assume the code in OptimizerVisitor#setConstField is not @CS friendly. That code has an early return for Integer and Double. > OptimizerVisitor#setConstField not @CS friendly > ----------------------------------------------- > > Key: GROOVY-8383 > URL: https://issues.apache.org/jira/browse/GROOVY-8383 > Project: Groovy > Issue Type: Bug > Reporter: Paul King > > {code} > @groovy.transform.CompileStatic > def method() { > Long wrapper = 2L > long prim = 2L > } > method() > {code} > gives: > {noformat} > java.lang.NoSuchFieldError: $const$0 > {noformat} > swapping the second {{2L}} with {{3L}} or {{wrapper}} side steps the problem. > The primitive and wrapper constants are being deemed the same but the types > won't match ({{J}} vs {{Ljava/lang/Long;}}). Other types are also affected > but seemingly not int or double. Swapping the order has no affect. I assume > the code in OptimizerVisitor#setConstField is not @CS friendly. That code has > an early return for Integer and Double. > In addition, the current implementation has a limitation if the user uses > field names similar to what the visitor generates, e.g. {{$const$0}}. A > similar error will occur if such a field exists but has the wrong type: > {code} > class Bar { > private String $const$0 = 'bar' > def method2() { > Long wrapper3 = 20L > } > } > new Bar().method2() // => NoSuchFieldError > {code} -- This message was sent by Atlassian JIRA (v6.4.14#64029)