1.1 compiler bug?

[ak]

Suppose we have following:

public class A {
public int do1() {...}
public int do2() {...}
}

public interface Ai {
int do1();
int do2();
}

public class B extends A implements Ai {
//everything are already implemented by A
}

public class C implements Ai {
public int do1() {...}
public int do2() {...}
}

public class ATest {
public static void main(String [] args) {
Ai ai = new B();
ai.do1();
}
}

A is existing JDK class.

I can compile these all in java 1.3, but not in java 1.1.
1.1 compiler complains: reference to do1 is ambiguous. it is defined in int
do1() and int do1().
So to compile this with 1.1 I need to cast ai to B:

Ai ai = new B();
((B)ai).do1();


Is it a known bug in 1.1?

any ideas or comments?

thanks in advice

Andrei

 

[VisionSet]

Suppose we have following:

public class A {
public int do1() {...}
public int do2() {...}
}

public interface Ai {
int do1();
int do2();
} ....
So to compile this with 1.1 I need to cast ai to B:

Ai ai = new B();
((B)ai).do1();


Is it a known bug in 1.1?

The only thing I can think of is maybe the syntax enforcement v
interpretation is a little sloppy in the interface, try making the
attributes in the interface explicitly public.

 

[ak]

The only thing I can think of is maybe the syntax enforcement v
interpretation is a little sloppy in the interface, try making the
attributes in the interface explicitly public.

interface methods are always public
it is mistake to write "public" in method definition of interface.

 

[VisionSet]

interface methods are always public
it is mistake to write "public" in method definition of interface.

You ask about possible bugs.

I give you a suggestion and you tell me what it *should* do.

If it did what it was supposed to do it wouldn't be a bug would it!

It is not a mistake to declare an interface with explicit public methods.
I know they are public anyway what ever you do that is why I said try making
them **explicitly** public. Explicitly implying - not the implicit way they
are public anyway!!

If it is broken then this is a remote possibilty.

Sheesh!

 

[Harald Hein]

interface methods are always public
Yes.

it is mistake to write "public" in method definition of interface.

No.

 

[Thomas G. Marshall]

Suppose we have following:

public class A {
public int do1() {...}
public int do2() {...}
}

public interface Ai {
int do1();
int do2();
}

public class B extends A implements Ai {
//everything are already implemented by A
}

public class C implements Ai {
public int do1() {...}
public int do2() {...}
}

public class ATest {
public static void main(String [] args) {
Ai ai = new B();
ai.do1();
}
}

A is existing JDK class.

I can compile these all in java 1.3, but not in java 1.1.
1.1 compiler complains: reference to do1 is ambiguous. it is defined
in int do1() and int do1().
So to compile this with 1.1 I need to cast ai to B:

Ai ai = new B();
((B)ai).do1();


Is it a known bug in 1.1?

any ideas or comments?

Is this really the test harness you used: Did you mean to use class C in
some way that got axed before pasting it here, because it is dangling in
hyperspace at the moment.

 

[ak]

The idea behind is pretty simple:

A is existing jdk class.
Ai is interface with same methods as A.
B extends A and implements Ai.
C is my own implementation of Ai.

B works with Files.
C do same things as B with arrays.

I want to use my interface Ai for files and arrays - so I have only one
implementation for both cases.

I found now another way (B uses now A as delegate instead of inheritance)
but I dont like it - I need to reimplement every method in B.

Suppose we have following:

public class A {
public int do1() {...}
public int do2() {...}
}

public interface Ai {
int do1();
int do2();
}

public class B extends A implements Ai {
//everything are already implemented by A
}

public class C implements Ai {
public int do1() {...}
public int do2() {...}
}

public class ATest {
public static void main(String [] args) {
Ai ai = new B();
ai.do1();
}
}

A is existing JDK class.

I can compile these all in java 1.3, but not in java 1.1.
1.1 compiler complains: reference to do1 is ambiguous. it is defined
in int do1() and int do1().
So to compile this with 1.1 I need to cast ai to B:

Ai ai = new B();
((B)ai).do1();


Is it a known bug in 1.1?

any ideas or comments?

Is this really the test harness you used: Did you mean to use class C in
some way that got axed before pasting it here, because it is dangling in
hyperspace at the moment.

 

[Thomas G. Marshall]

The idea behind is pretty simple:

A is existing jdk class.
Ai is interface with same methods as A.
B extends A and implements Ai.
C is my own implementation of Ai.

B works with Files.
C do same things as B with arrays.

I want to use my interface Ai for files and arrays - so I have only
one implementation for both cases.

I found now another way (B uses now A as delegate instead of
inheritance) but I dont like it - I need to reimplement every method
in B.



"Thomas G. Marshall"

Suppose we have following:

public class A {
public int do1() {...}
public int do2() {...}
}

public interface Ai {
int do1();
int do2();
}

public class B extends A implements Ai {
//everything are already implemented by A
}

public class C implements Ai {
public int do1() {...}
public int do2() {...}
}

public class ATest {
public static void main(String [] args) {
Ai ai = new B();
ai.do1();
}
}

A is existing JDK class.

I can compile these all in java 1.3, but not in java 1.1.
1.1 compiler complains: reference to do1 is ambiguous. it is defined
in int do1() and int do1().
So to compile this with 1.1 I need to cast ai to B:

Ai ai = new B();
((B)ai).do1();


Is it a known bug in 1.1?

any ideas or comments?

Is this really the test harness you used: Did you mean to use class
C in some way that got axed before pasting it here, because it is
dangling in hyperspace at the moment.

As a general comment, I've seen the lack of MI tempt people into duplication
of code.

The solution is almost always to separate out the common code into the
hierarchy itself (if possible), or to use the decorator pattern, or to
simply separate the sucker into it's own class accessed on it's own in
delegation, like you suggest.

Unless I'm missing something, that's life in the big city.

 

[Tim Tyler]

:

No.

Relatively harmless - but a mistake nontheless.