feat!: Update to Groovy 4

[matrei]

No description provided.

[sdelamo]

Could you change the failing test from @ignore to PendingFeature instead?

[sdelamo]

@matrei Thanks for doing this PR. Moreover, thanks for doing such a granular PR. It makes review really easy.

[sdelamo]

why this ?

[matrei]

The test won't compile with the @Entity annotation present when extending another domain class.

We could also do this:

// With Groovy 4, it is currently not possible to extend domain classes: https://issues.apache.org/jira/browse/GROOVY-5106
@Entity
class StringPropertyValue /*extends AbstractCustomPropertyValue*/ {

    String stringValue

    static constraints = {
        stringValue (nullable: true)
    }

    StringPropertyValue (String value) {
        this.stringValue = value
        this.valid = true
    }
}

[sdelamo]

https://issues.apache.org/jira/browse/GROOVY-5106 seems to be fixed. are we not using a groovy version which does not contain the patch?

[sdelamo]

@paulk-asert do you know about this?

[matrei]

It is the fix to that issue that causes the problem with extending domain classes.

[paulk-asert]

If you have the following classes in Java:

class Parent implements Iterator<CharSequence> { ... }
class Foo extends Parent implements Iterator<String> { ... }

Java will tell you to remove one of the Iterator interface clauses:

'java.util.Iterator' cannot be inherited with different type arguments: 'java.lang.CharSequence' and 'java.lang.String'. 

Groovy 3 allowed that to co-exist since after type erasure, it folds down onto one interface and the one you want was kept. But that was a kludge and information was lost, so Groovy 4 does the same as Java here.

In this case we have (note duplicated GormEntity and Entity with different types):

class AbstractCustomPropertyValue implements GroovyObject, GormEntity<AbstractCustomPropertyValue>, GormEntityDirtyCheckable, WebDataBinding, DomainClass, grails.gorm.Entity<AbstractCustomPropertyValue>, DirtyCheckable.Trait.FieldHelper, GormValidateable.Trait.FieldHelper { ... }
class StringPropertyValue extends AbstractCustomPropertyValue implements GormEntity<StringPropertyValue>, WebDataBinding, DomainClass, grails.gorm.Entity<StringPropertyValue>, DirtyCheckable.Trait.FieldHelper, GormValidateable.Trait.FieldHelper { ... }

If supporting inheritance of entities is desirable, the @Entity transform would need to be made smarter. There might be a few different ways to make it work. Perhaps only abstract classes could be extended and they might not need the original interface added. Perhaps non-final classes could use a generic type like ? extends AbstractCustomProperty (in this case).

[paulk-asert]

My example was for the previous test but the discussion still applies. For the previous test, I think you can also remove @Entity from the abstract parent class (and remove it from mockDomains too) and the test still passes prior to this PR at least.

[sdelamo]

@matrei can we update the test and start a breaking changes section in the docs telling the user about this change?

[matrei]

@sdelamo Yes, we could. Are you aware of any use cases where extended domain classes are also used concretely? That kind of usage would obviously not work anymore.

[puneetbehl]

You could try running https://github.com/grails/grails-functional-tests project to see if anything is broken.

[matrei]

You could try running https://github.com/grails/grails-functional-tests project to see if anything is broken.

Hi @puneetbehl, is it possible to run the grails-functional-tests project on the this branch?

[puneetbehl]

Yes, you would need to make certain changes to the build.gradle file of the project.

[sdelamo]

I am going to merge this into 7.0.x branch. We can work on the @PendingFeature tests in separate PRs. Thanks for the work.