[
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}
And if iti 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}
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.
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}
> 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}
> And if iti 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
(v6.4.14#64029)
