Why fields cannot be "blank finals" in java interfaces?

Friends,Interfaces limit or disallow the usage of "blank finals" - the same implies the feature that fields are implicitly static and final.But why is this restriction - why "blank finals" are disallowed in interfaces?Thanks,Sundar
[266 byte] By [Sundar_1976a] at [2007-11-27 10:05:11]
# 1
See my reply to your other post, then gimme dukes :-)What use did you see for a blank final?
georgemca at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 2
> See my reply to your other post, then gimme dukes> :-)> > What use did you see for a blank final?yeah, just tell me what use? if it's blank, there's nothing in it; if it's final you cannot change it!:)
manuel.leiriaa at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 3
Final fields must be set in constructors or initilizers.Static fields (as is the case here) must be set inplace or in static initializers.And since interfaces can neither define constructors nor initializers blank (final) fields are not allowed in interfaces.
dwga at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 4

I suspect the real question here - or at least the underlying misunderstanding - is "Why can't interfaces have fields other than public static final ones?"

The reason being, an interface defines what public API is being exported, and that should consist of methods. Fields would be an implementation detail, and hence don't belong on a publicly visible API

georgemca at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 5

Ok ...I understand this way - quote bruce eckel -

"blank finals provide much more flexibility in the use of the

final keyword since, for example, a final field inside a class can now be

different for each object and yet it retains its immutable quality."

And any class that implements the interface would be able to access the variable via its constructor - so can't a blank final be typically initialized this way (in line with the quotes above) and so we have different values for each instance of the object which are typically "final" to that instance.

Please correct me if I am wrong.

Sundar_1976a at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 6
> so we have different values for each instance of the objectSuch a thing doesn't belong in an interface.~
yawmarka at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 7

> And any class that implements the interface would be

> able to access the variable via its constructor - so

> can't a blank final be typically initialized this way

> (in line with the quotes above) and so we have

> different values for each instance of the object

> which are typically "final" to that instance.

>

> Please correct me if I am wrong.

You would then be using the interface to dictate a part of the implementation. Not what they're there for

georgemca at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 8
I meant each instance of the class that implements the interface.
Sundar_1976a at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 9
> I meant each instance of the class that implements> the interface.I know what you meant
georgemca at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 10

Is this the question:

class C {

static final int X;

static {

X = 17;

}

}

interface I {

int Y;

static {

Y = 17;

}

}

Why is class C allowed but not interface I?

BigDaddyLoveHandlesa at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 11

> I meant each instance of the class that implements the interface.

Your meaning was clear to me. Same answer applies. An interface is intended to be used as a behavioral contract, not an explicit data contract. An implementation's data can be implied by an interface, but not enforced. Not to mention that interface fields are implicitly public, final and static as defined by the JLS*. The fact that you want a value for each instance should tell you why such a field defined in the interface is impossible; you can't have a static field apply to each instance by definition.

~

* http://java.sun.com/docs/books/jls/third_edition/html/interfaces.html#9.3

yawmarka at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 12

> Ok ...I understand this way - quote bruce eckel -

>

> "blank finals provide much more flexibility in the

> use of the

> final keyword since, for example, a final field

> inside a class can now be

> different for each object and yet it retains its

> immutable quality."

That would be an instance variable (i.e., non-static) rather than a class variable (static). There's no reason for an interface to dictate that all implemenations must have a particular variable for maintaining their state. There's no good use for a "blank final" in interfaes.

jverda at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 13

To be precise - when interfaces allow classes which implement them to provide definition for the methods in it in their own way, why does it not allow the same for it's fields?

As detailed below, when class X and Y are allowed to provide different implementations for "display()", they are forced to use the variable i with its value 10 - reason being they are static and final. The scenario could be different if the variable i is a "blank final" - so class X and Y could have provided different values in their implmentations before it's used.

interface A

{

int i = 10;

void display();

}

class X implements A

{

void display()

{

System.out.println("Implementation in class X");

}

}

class Y implements A

{

void display()

{

System.out.println("Implementation in class Y");

}

}

class Test

{

public static void main(String args[]) {

X x = new X();

Y y = new Y();

x.display();

y.display();

}

}

Sundar_1976a at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 14

> To be precise - when interfaces allow classes which

> implement them to provide definition for the methods

> in it in their own way, why does it not allow the

> same for it's fields?

Which methods must be present is part of the contract--the behavior.

Fields are just an internal implementation detail. No class should ever be required to provide any field--and in fact Java (wisely) doesn't allow you to require a class to provide a field.

The static final fields that interfaces allow are different from implementation-specifc, instance-specific fields because they're associated with the type as a whole--not with any particular implementation of the type, and not with any instance--and because they're "constant" (i.e. final).

Again, it would make no sense to say, "All implementations must provide this field, with some value that they determine."

> As detailed below, when class X and Y are allowed to

> provide different implementations for "display()",

> they are forced to use the variable i

You can't (and shouldn't try to) force implementations to use any particular variable.

jverda at 2007-7-13 0:40:11 > top of Java-index,Java Essentials,Java Programming...
# 15
> To be precise - when interfaces allow classes which> implement them to provide definition for the methods> in it in their own way, why does it not allow the> same for it's fields?Reply #11, among others.~
yawmarka at 2007-7-21 23:15:01 > top of Java-index,Java Essentials,Java Programming...
# 16

> To be precise - when interfaces allow classes which

> implement them to provide definition for the methods

> in it in their own way, why does it not allow the

> same for it's fields?

>

Either you're clueless, can't read, or are delusional and think the world's going to change to what you think it should be if only you deny reality long enough.

You have been supplied everything you need to figure it out for yourself with just a basic understanding of Java terminology.

It has in fact been spelt out for you.

> scenario could be different if the variable i is a

> "blank final" - so class X and Y could have provided

> different values in their implmentations before it's

> used.

>

In which case you'd no longer have something that it makes sense to define in an interface. Sheesh....

In fact it makes very little sense to define fields in an interface as is.

jwentinga at 2007-7-21 23:15:01 > top of Java-index,Java Essentials,Java Programming...