[
https://issues.apache.org/jira/browse/GROOVY-12473?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18129693#comment-18129693
]
Eric Milles commented on GROOVY-12473:
--------------------------------------
You can force field (attribute) resolution with "Float.@NaN". I'll take a look
at property order. I'm fairly certain that access method is preferred over
field, regardless of visibility.
> SC: static compilation in some situation prefers boolean getter over static
> field and produces cast exception
> -------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-12473
> URL: https://issues.apache.org/jira/browse/GROOVY-12473
> Project: Groovy
> Issue Type: Bug
> Affects Versions: 2.5.23, 3.0.25, 5.0.3, 4.0.33, 5.1.3, 6.0.0
> Reporter: Björn Kautler
> Priority: Major
>
> Given this snippet:
> {code:groovy}
> @groovy.transform.CompileStatic
> def foo() {
> (Float as Class<Float>).NaN
> }
> foo().toString()
> {code}
> It fails at runtime with a class-cast exception, because static compilation
> decides it would be a good idea to interpret the {{NaN}} not as the static
> field, but as {{isNaN()}} call, casting the {{Class<FLoat>}} to {{Float}}
> which fails of course.
> (This might seem like forged example, of course you would usually do
> {{Float.NaN}} which works. Nevertheless it should work and not produce cast
> exception, and if you use {{Float.NaN}} in a Spock assertion with a
> SC-optimized Spock, you get exactly that cast exception)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
