Regarding Interface..

[frank]

Hi friends,
have some doubt in Interface...
they are.....
1. Why the Variables are Private static final in Interface..... where
all the methods
are Public...

2. interface a
{
private static final int a=10;
}

interface b
{
private static final int a=50;
}

class c implements a,b
{
which value of 'a' is available Here....?
}


I run it but it show ambiguity Error ....

I think the Problem is in Multiple Inheritance is still in Java....?
Please clear...
thanks In Advance....

 

[Mike Schilling]

Hi friends,
have some doubt in Interface...
they are.....
1. Why the Variables are Private static final in Interface.....
where
all the methods
are Public...

Fields in interfaces are implicitly public, static, and final. You
can specify those qualifiers if you like, but they're unnecessary.

2. interface a
{
private static final int a=10;
}

That won't compile:

javac -g a.java
a.java:3: modifier private not allowed here
private static final int a=10;
^
1 error

 

[charlesbos73]

There are so many things wrong with your post
I don't know where to start.

1. Why the Variables are Private static final in Interface..... where
all the methods
are Public...

Why the uppercase for *v*ariables, *p*rivate and *i*nterface and
*p*ublic ?

2. interface a
{
private static final int a=10;
}

interface b
{
private static final int a=50;
}

class c implements a,b
{
which value of 'a' is available Here....?

}

mu! (that's the only valid answer to your question)

Java interfaces and classes, by convention, should start
with an uppercase.

Your premises are wrong.

As Mike Schilling answered you, fields are public and static
in interfaces.

But consider this:

- a man has a hat
- that man is sitting in a car

Is there a hat in the car?

interface A {

class B {
private volatile int a;
}

}

which compiles perfectly fine (volatile and final
are incompatible modifiers, I just used volatile
to make the point clear).

Is there a non-public non-final field in this
interface? (remember: is there a hat in the car?)

For some definition of "contains" the answer is
murky at best.

I think the Problem is in Multiple Inheritance is still in Java....?

Actually multiple inheritance can be achieved in Java
by using interface inheritance and it works perfectly
fine. You don't have the diamond problem.

Note that you can also avoid the circle/ellipse "problem"
by doing OO over immutable objects (the circle/ellipse
problem is not a problem due to inheritance but due to
mutability) but I disgress.

Anyway, the matter gets quickly complicated due to Java allowing
both (Java) interface inheritance (and multiple interface
inheritance) and concrete implementation inheritance by
extending (Java) classes (single concrete inheritance).

It gets even more complicated with Java having its own
definition of the term 'interface' and 'class' which
definitely do not match the OO definition of these
terms.