[ 
https://issues.apache.org/jira/browse/GROOVY-8383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King closed GROOVY-8383.
-----------------------------

> 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
>            Assignee: Paul King
>            Priority: Major
>             Fix For: 2.4.13
>
>
> {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}
> And if it happens to be the "correct" type it can lead to weird errors:
> {code}
> class Bar {
>   private static long $const$0 = 42
>   def method2() {
>     long prim4 = 21L
>   }
> }
> assert new Bar().method2() == 42 // expected 21!
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to