f



1.1 compiler bug?

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


0
k.andrei (63)
11/9/2003 1:20:28 PM
comp.lang.java.programmer 52714 articles. 1 followers. Post Follow

8 Replies
431 Views

Similar Articles

[PageSpeed] 40

"ak" <k.andrei@gmx.de.spam> wrote in message news:boleus$9l5$1@online.de...
> 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.

-- 
Mike W


0
spam19 (1056)
11/9/2003 4:25:09 PM
"VisionSet" <spam@ntlworld.com> schrieb im Newsbeitrag
news:5Qtrb.986$gS4.91@newsfep4-winn.server.ntli.net...
>
> "ak" <k.andrei@gmx.de.spam> wrote in message
news:boleus$9l5$1@online.de...
> > 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.

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





0
k.andrei (63)
11/9/2003 5:24:47 PM

"ak" <k.andrei@gmx.de.spam> wrote in message news:bolt8v$hi4$1@online.de...
> > > 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.
>
> 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!

-- 
Mike W


0
spam19 (1056)
11/9/2003 5:53:25 PM
"ak" wrote:

> interface methods are always public

Yes.

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

No.

0
speechless (234)
11/9/2003 6:07:54 PM
ak <k.andrei@gmx.de.spam> coughed up the following:

> 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.



0
11/10/2003 4:31:22 AM
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" <tgm2tothe10thpower@hotmail.replaceTextWithNumber.com>
schrieb im Newsbeitrag news:uwErb.15621$y95.4331@nwrdny01.gnilink.net...
> ak <k.andrei@gmx.de.spam> coughed up the following:
>
> > 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.
>
>
>


0
k.andrei (63)
11/10/2003 8:14:31 AM
ak <k.andrei@gmx.de.spam> coughed up the following:

> 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"
> <tgm2tothe10thpower@hotmail.replaceTextWithNumber.com> schrieb im
> Newsbeitrag news:uwErb.15621$y95.4331@nwrdny01.gnilink.net...
>> ak <k.andrei@gmx.de.spam> coughed up the following:
>>
>>> 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.


0
11/10/2003 4:03:15 PM
Harald Hein <speechless@gmx.de> wrote or quoted:
> "ak" wrote:

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

Relatively harmless - but a mistake nontheless.
-- 
__________
 |im |yler  http://timtyler.org/  tim@tt1lock.org  Remove lock to reply.
0
tim184 (690)
11/22/2003 11:24:08 AM
Reply: