groovy-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul King (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (GROOVY-8383) OptimizerVisitor#setConstField not @CS friendly
Date Sun, 19 Nov 2017 00:38:00 GMT

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

  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.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Mime
View raw message