Interface containing field without initialization expression incorrectly compiles

I reduced the priority to "minor", because this is no bug that is causing any problems. I am even tempted to change this into an improvement. Even though we want to be near Java, we don't have to follow all rules. We don't require final local variables for inner classes and don't make full generics checks. We do not even have static type based method preselection.

So for me the first question is why we absolutely have to do this check. Can you answer this?

Happy with the lower priority.

One very common use for interfaces is to encapsulate runtime constants/environmental dependencies,etc. In this usage, I'm not sure that I want 'blank finals' in my interface.

Interestingly, I COULD take an opposite stance and make some sort of case for having blank finals in an interface...for precisely the same reason: capture values that are constant for the duration of this run, but which may not be universally so. If this were to happen, would one have to give an interface a constructor like an enum? Or setters that look like:

setX(x) {
  if (x.initialised)
    barf somehow
  this.x = x
  x.initialised = true
}

We already have this:

abstract class AC {
  String s
}

Your comment suggests that there is/should be no distinction?

if you don't check, what to do about:

interface II {
  Integer i
  Integer 2i = i * 2
}

Currently (1.7b2), one gets:

groovy> interface II {
groovy>   Integer i
groovy>   Integer i2 = i * 2
groovy> }
groovy> println II.i
groovy> println II.i2

Exception thrown

java.lang.IncompatibleClassChangeError: Found interface II, but class was expected

	at II.<clinit>(ConsoleScript0:3)

	at ConsoleScript0.class$(ConsoleScript0)

	at ConsoleScript0.$get$$class$II(ConsoleScript0)

	at ConsoleScript0.run(ConsoleScript0:6)

Blank final interfaces may not be such a bad idea if done deliberately. At the moment, one just gets a shock and assumes that one has found a bug...which one has, even if it may eventually lead to an improved idea.

In Groovy variables have always an value. So your blanks in the interface will have a value of null or 0, depending on if it is a primitive type or not. Of course you are usually not defining a field in an interface to have a null value. You can get that more easily by using null directly. But for the sake of incremental development I think that it makes sense to allow someone to define some fields in the interface and think about the right values later.

Things like an interface constructor is not intended, no. As for your IncompatibleClassChangeError,could you pleae fill a new issue for this?

Is there anything to be done on this issue? The IncompatibleClassChangeError was solved through GROOVY-3830 and the interface fields are correctly having their initial values - null/0/false

interface I {
  String s
  int i
  boolean b
}
println I.s // null
println I.i // 0
println I.b // false

So, what remains to be done in this JIRA?

I close it as duplicate of GROOVY-3830 then