You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Andres Almiray <aa...@gmail.com> on 2018/05/30 11:35:41 UTC

Groovy 2.5.0 Bug

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.

Re: Groovy 2.5.0 Bug

Posted by Russel Winder <ru...@winder.org.uk>.
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

Re: Groovy 2.5.0 Bug

Posted by Paul King <pa...@asert.com.au>.
I created this:
https://issues.apache.org/jira/browse/GROOVY-8617

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 <su...@apache.org> 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
>

Re: Groovy 2.5.0 Bug

Posted by "Daniel.Sun" <su...@apache.org>.
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