groovy

You get a runtime error, is that not OK for you?
The problem is, that we could provide a compile time error here, but only because a static field is used. The compiler might not be able to ensure this for fields used on instances.

The issue is not when the error message occurs, runtime is fine, the problem is that there is an error here at all.

The problem is that the expression statement:

Foobar.blah.plus ( 2 )

works fine, but the supposedly same semantic statement:

Foobar.blah += 1

fails. I guess the issue is whether the += operator is seen as an assignment of the reference (which it isn't semantically even though it is syntactically) or whether it is a modifier of the object as the plus method call is.

The issue is one of consistency, and I am not sure Groovy has it just now.

I think I do not understand yet.

a += 1

is not the same as

a.plus(1)

it is the same as

a = a.plus(1)

so if a is final, the assignment will fail, but not the plus. In the case above Foobar.blah.plus ( 2 ) means to create a new list with the additional item 2 and assign the new list to the old one. The list stored in blah, but not final, so no exception. Foobar.blah += 1, is the same with two differences, the "2" is a "1" now and in the end I am assigning a new value to blah. Since blah is a final field, the VM will throw the runtime message. There is nothing wrong with that.

The only thing Groovy in combination with the VM ignores here is the final modifier to local variables. Yes, for this we could write a compile time test and throw a compile time error.

I have no problem with the above, it is reasonable and consistent (sort of

However, if this is the case then shouldn't:

final x = []
x += [ 1 ]

result in an exception for exactly the same reasons?

If not then we need to introduce language to describe the difference. Python has done this using the terms mutable and immutable. Tuples and Lists behave differently under +=.

final on methods and fields is tested by the VM, final on local variables is not. So groovy must check that and it doesn't. So yes, this is a bug, inconsistency or what you want to call it.

It seems like final on fields is not checked according to the following example:

class C {
    final a = 0
    void changeA() {
        a = a + 1
    }
    final b = 0
    final setB(val) {
        b = val
    }
}
c = new C()
c.changeA()
c.changeA()
assert c.a == 2
c.b = 1
assert c.b == 1

Just commenting on status of current implementation:
Tord's example is checked - it is on fields and gives an appropriate error.
Russel's example isn't checked yet - local variable case.

This is listed as a subtask of GROOVY-4681 but in reality, doesn't the description of GROOVY-4681 capture the remaining issue(s)? I.e. can we close one of them as a duplicate?