[
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)
