Compilation error when trying to assign int to Serializable

[mauromol]

Consider this Java class:

package testserializable;

import java.io.Serializable;

public class MyClass {

	private Serializable id;
	
	public Serializable getId() {
		return id;
	}
	
	public void setId(Serializable id) {
		this.id = id;
	}
}

and this Groovy class:

package testserializable

import groovy.transform.CompileStatic

@CompileStatic
class TestSerializable {
	void foo() {
		def c = new MyClass(id: -1)
	}
}

An error is shown in the editor:

Groovy:[Static type checking] - Cannot assign value of type int to variable of type java.io.Serializable

Same problem if I do:

def c = new MyClass()
c.id = -1

Fixed if I do: -1 as Integer.

This is a regression for sure, but I don't know when it started to appear.
Using Greclipse 4.7.0.v202208210205-e2112.

[eric-milles]

This is the source of the issue: d571b94

[eric-milles]

https://issues.apache.org/jira/browse/GROOVY-10744

Regression for literals. But also fields, methods and variables of primitive type give error.

[mauromol]

Is this issue the source of the following problem as well?

[eric-milles]

The TL;DR is you can use double-quotes to indicate a String constant in this situation. You may also be able to write "(String)'b'" if you want to stick with single quotes.

To support char attributes like vanilla groovyc (post GROOVY-9206), I had to make a concession. There is a discussion of single-character, single-quotes attribute values here: #1390 (comment)

[mauromol]

Hmmm... I understand why you did this change. Still, these kind of things are hurting Greclipse... Is the main source of the problem in some way related to #175?

[eric-milles]

It is not too late to revert this before 4.7.0 is finalized on Sep 30th. However it has already been released into the 3.0.13 and 4.0.5 batch compilers. If annotation attribute constants are as before, you would be required to use a typecast to indicate a char value.

@interface A { char value }
@A( (char)'c' )
class C { ... }

@chrylis @cstamas @mauromol

[mauromol]

IMHO, one-character strings in annotation values are much more frequent than char annotation values... so I would prefer the compromise on char rather than on String. But I leave the decision to you. Indeed, it was not nice at all to see those @Option annotation fail compilation whole of a sudden, with perfectly legal assignments :-(

[eric-milles]

Assignability of non-void primitives to Serializable and single-character annotation attribute values are fixed. Release will be out tomorrow (Sep 30th).