Groovy 2.5.0 Bug

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Groovy 2.5.0 Bug

Andres Almiray
Hello everyone,

Tried to upgrade Griffon to the latest Groovy 2.5.0 and found a problem with Spock (1.1-groovy-2.4). Together with Jochen and Paul (we're at Gr8Conf right now) we had a look at the problem and reduced it to the following code (self contained, runnable with GroovyConsole):

----------------------
@Grab("org.spockframework:spock-core:1.2-groovy-2.4-SNAPSHOT")
@Grab("org.codehaus.griffon:griffon-javafx:2.14.0")
@GrabResolver("https://oss.sonatype.org/content/repositories/snapshots/")

import griffon.javafx.beans.binding.*
import groovy.transform.Canonical
import javafx.beans.binding.Binding
import javafx.collections.FXCollections
import javafx.collections.ObservableList
import spock.lang.Specification
import spock.lang.Unroll

import java.util.function.Predicate

@Unroll
class FilteringBindingsSpec extends Specification {
    def "Filter then findFirst in list with defaultValue"() {
        given:
        Box defaultValue = new Box(6)
        ObservableList<Box> items = FXCollections.observableArrayList()
        Predicate<Box> filter = { it.id % 2 == 0 }
        Binding binding = FilteringBindings.filterThenFindFirst(items, defaultValue, filter)

        expect:
        defaultValue == binding.get()

        when:
        items.addAll([new Box(1), new Box(2), new Box(3), new Box(4)])

        then:
        new Box(2) == binding.get()
    }

    def "Filter then findFirst #type in list with defaultValue"() {
        given:
        ObservableList items = FXCollections.observableArrayList()
        Binding binding = FilteringBindings."filterThenFindFirst${type}"(items, defaultValue, predicate)

        expect:
        defaultValue == binding.get()

        when:
        items.addAll(values)

        then:
        result == binding.get()

        where:
        type      | defaultValue | predicate                   | values                    | result
        'Boolean' | true         | { it }                      | [false, true, false]      | true
        'Integer' | 6            | { it % 2 == 0 }             | [1, 2, 3, 4, 5]           | 2
        //'Long'    | 6L           | { it % 2 == 0 }             | [1L, 2L, 3L, 4L, 5L]      | 2L
        //'Float'   | 6f           | { it % 2 == 0 }             | [1f, 2f, 3f, 4f, 5f]      | 2f
        //'Double'  | 6d           | { it % 2 == 0 }             | [1d, 2d, 3d, 4d, 5d]      | 2d
        //'String'  | '6'          | { it.toInteger() % 2 == 0 } | ['1', '2', '3', '4', '5'] | '2'
    }

    @Canonical
    private static class Box {
        int id
    }
}
----------------------

The error we get is

JUnit 4 Runner, Tests: 1, Failures: 2, Time: 175
Test Failure: Filter then findFirst #type in list with defaultValue(FilteringBindingsSpec)
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object 'true' with class 'java.lang.Boolean' to class 'FilteringBindingsSpec$Box'
    at FilteringBindingsSpec.Filter then findFirst #type in list with defaultValue(ConsoleScript0:49)

Test Failure: Filter then findFirst #type in list with defaultValue(FilteringBindingsSpec)
org.codehaus.groovy.runtime.typehandling.GroovyCastException: Cannot cast object '6' with class 'java.lang.Integer' to class 'FilteringBindingsSpec$Box'
    at FilteringBindingsSpec.Filter then findFirst #type in list with defaultValue(ConsoleScript0:49)

Apparently there's some state left from the first feature method that leaks into the second and third. This does not occur with Groovy 2.4.15 and Spock 1.1-groovy-2.4


-------------------------------------------
Java Champion; Groovy Enthusiast
JCP EC Associate Seat
http://andresalmiray.com
http://www.linkedin.com/in/aalmiray
--
What goes up, must come down. Ask any system administrator.
There are 10 types of people in the world: Those who understand binary, and those who don't.
To understand recursion, we must first understand recursion.
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.5.0 Bug

Daniel.Sun
You have better to submit a JIRA issue to track it. The issue is critical
IMO...

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html
Daniel Sun
Apache Groovy committer

Blog: http://blog.sunlan.me
Twitter: @daniel_sun
Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.5.0 Bug

paulk_asert

Probably worth a triage step to work out whether it is principally a
Groovy or Spock issue. There was a similar issue we fixed earlier on
the Spock side (fix currently only in 1.2-groovy-2.4-SNAPSHOT).
That is where I suspect the bug will be. Whether we can possibly step around
the issue from the Groovy side only remains unclear until further investigation.
Basically if you split this:
    def x = 3
into this:
    def x
    x = 3
at the AST transform level, Groovy makes certain assumptions about how the
variable expression for x on the second line should look and whether node metadata
for things like inferred type should be copied into the new node. Those assumptions
are more important in Groovy 2.5. We'll have to look into what the expanded AST for
the Spock 'where:' clause looks like in more detail.

The other possibility is that on the Groovy side we haven't created a new node
somewhere that we need to because while something might seem the same
at one point, it isn't the same and needs its own (different) metadata further
in the processing.

I can look at this in a couple of weeks but I head off on a cruise after gr8conf
and won't have connectivity for most of it. So, if someone else wants to take
a look, that would be great.


Cheers, Paul.


On Thu, May 31, 2018 at 10:09 AM, Daniel.Sun <[hidden email]> wrote:
You have better to submit a JIRA issue to track it. The issue is critical
IMO...

Cheers,
Daniel.Sun




--
Sent from: http://groovy.329449.n5.nabble.com/Groovy-Dev-f372993.html

Reply | Threaded
Open this post in threaded view
|

Re: Groovy 2.5.0 Bug

Russel Winder-3
In reply to this post by Andres Almiray
On Wed, 2018-05-30 at 13:35 +0200, Andres Almiray wrote:
> Hello everyone,
>
> Tried to upgrade Griffon to the latest Groovy 2.5.0 and found a
> problem
> with Spock (1.1-groovy-2.4). Together with Jochen and Paul (we're at
> Gr8Conf right now) we had a look at the problem and reduced it to the
> following code (self contained, runnable with GroovyConsole):
>

Does Spock guarantee that a build for Groovy 2.4 works with Groovy 2.5?
Given that Spock releases different artefacts for each minor version of
Groovy, I'd suggest no. Thus it comes as no surprise there is a
problem. Clearly time for a Spock 1.1-groovy-2.5.

--
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

signature.asc (849 bytes) Download Attachment