When using the generic compiler, I noticed that you can't say:

public class Monkey<T implements MonkeyFood>

if MonkeyFood is an interface. You have to say:

public class Monkey<T extends MonkeyFood>

Why is this? Why don't you use "implements" when we're talking about interfaces and maintain symmetry with the other case in the language?

Is the answer purely technical (e.g doing it the other way would be hard), a bug, an oversight, or something that's going to be corrected? It gives a rather cryptic "> expected" error right now, which is confusing.

 

 

I just reread the specification, and this seems like it should be allowed.

To reproduce, compile the following 2 classes with the latest (released) generic compiler:

Monkey.java:

public class Monkey<T implements MonkeyFood>
{
}

---

MonkeyFood.java:

public interface MonkeyFood
{
}

---

The error is:
Monkey.java:1: > expected
public class Monkey<T implements MonkeyFood>
^
Monkey.java:3: '{' expected
}
^
2 errors

 

 

Very interesting.

I reread the participant draft, April 27, 2001, and although the language syntax uses "extends" the example 2 uses "implements" (both these on page 3).

So here are my thoughts after chewing over this while I chewed my lunch.

The examples below are reworks of the expression

Foo<T extends AbstractCollection & Remote>

Background

This clause is specifying the bounds (plural) of a type parameter, which if absent is implicity "extends Object".

Points in favour of "extends"

1. If the clause is absent it is implicitly "extends Object" which is how the other "extends" works (and not how the "implements" works).

2. There are cases where you extend an interface eg

interface foo extends bar {}

and there are not cases where you "implement" a class.

Points in favour of "implements"

1. the other use of implements allows multiple types after it, whereas "extends" does not.

2. any more? Maybe that's why they chose "extends".

Lets not limit ourselves. Other options could be...

1 Use both
The type bound could be an (optional) extends with a single class, followed by an optional implements with multiple interfaces. this would be more consistent than either single keyword, and would imply the syntax of bound having at most 1 class, but possibly many interfaces. The only disadvantage to this would be (slight) verbosity.

example

Foo<T extends AbstractCollection implements Remote>

2. use a different keyword

eg "bounds", or "instanceof"

examples

Foo<T bounds AbstractCollection & Remote>
Foo<T instanceof AbstractCollection & Remote>

3 Use the field / parameter declaration syntax where the type precedes the variable (and therefore you don't use a keyword to introduce the bounds).

example.

Foo<AbstractCollection & Remote T>

As for my pick,?

Well to be honest I hadn't considered the issue before, so I WAS by default happy with "extends", but now having given it some thought, I think the hybrid form

Foo<T extends AbstractCollection implements Remote & Bar>

has a certain obviousness and elegance despite its slight verbosity.

What do the rest of you out there think?

 

 

Interesting thoughts. To my mind, not using implements simply smacks of laziness, but i guess once it's part of the language they'll come up with a more convincing reason to tell the public.

As for instanceof - definitely, absolutely, utterly not. The type is a type, not an instance. For the same reason, the <Thingy T> format is also out.

The format <T extends Thingy implements Doodad> looks right, but is actually a more signification change. What it says is that the type of T can actually be dynamic - rather than specifiying a ThingyDoodad type that extends Thingy and implements Doodad, you're allowing anything that's a Thingy and a Doodad. Unless you plan to allow this for ordinary reference types, I don't think you should allow it for parameterizations either.

 

 

Shrink,

I was not suggesting a change of semantics (if that is what you meant by "a more significant change").

From my reading of the proposal, the type can be anything that is a Thingy and a Doodad, which is why the spec says you must cast it (to a Thingy or a Doodad) before accessing any member that is not a member of Object. The whole point of generics is that the Type is dynamic (at least from the perspective of the generic class, tho' not from the perspective of the reference to the generic type).

What I was trying to do was suggest a different (improved or otherwise) syntax which I thought better captured those semantics, while overcoming the problems implied by the original post of this thread.

Maybe I should do a search thru' the Early Access Compiler source, the specs, the GJ home page etc and see if I can find some examples of declaring a bound with multiple types. It might shed some light on this construct.

Thanks for your analysis of instanceof and <Thingy T>, You are right (you know that already, but you might like to know that I agree).

 

 

Warm fuzzy glow... :-)

 

 

a copy of a mail I sent to the jsr mailing list about this :

---

this mail is a bit critical
so I have to apologize since I realize that all the work done
is the results of years of careful compromises....
nonetheless:
I took me a long while ( and a forum posting) to realize that
you could not write
<X implements Y>

so now you define
<X extends Y>
and
Myclass implements theYinterface
is a correct match...

I think I see your point (tell me if I am wrong)
in fact trough
<X extends Y>
you express the fact that "X is assignable to Y" (or somehting like that)
and that is a more flexible and potent expression.

(I have some theoretical qualms about that but I am not here to express them)
so that's a perfectly sound and strong idea
BUT
do you imagine the trainer's travail to explain that to students?
you spend hours to explain the technical, theoretical, philosophical
differences between "extends" and "implements" and suddenly pop!
things change!
I know the wonderful ambiguity of the english language would probably
permit this semantic twist, but to implement this in a computer language
is a really bad idea.

why not write instead something like :
<X isAssignableTo Y>

Ok I know! you'll get skinned alive if you introduce yet another keyword
in java!

what about a syntactic gimmick like :

< X =: Y>
or whatever is palatable to the compiler (and to programmers reading the
code)

(do not tell me that changing existing programs is much of a problem...)

---

My conclusion : terrible, but who cares?
having two senses for "extends" keyword does not seem
to hurt anybody.....
I am deeply hurt !

 

 

It looks like everyone in this Thread agrees that they would prefer to use both keywords extends and implements.

My suggestion on the syntax is to use ,'s between interfaces, and ;'s between types, instead of the &'s for example:

class Class1<TypeA extends Class2 implements Interface1, Interface2;
             TypeB implements Interface3, Interface4; 
             TypeC> {
}

I haven't seen anyone defending the usage of the current syntax using extends and &.

 

 

As a small sidenote to this discussion, I have a question of whether the following code should be treated as valid according to the draft specification? When I run it using the JSR14 prototype, I get a NullPointerException.

interface SomeInterface {}
class Foo<T extends SomeClass & SomeInterface> {}
class SomeClass {}
 
public class JSRMultipleTypeBounds {
    public static void main(String[] args) {}
}

The exception follows:

st-james: [~/Experiments/VarianceTest] % javac15 JSRMultipleTypeBounds.java
java.lang.NullPointerException
        at com.sun.tools.javac.comp.Check.checkOverride(Check.java:903)
        at com.sun.tools.javac.comp.Attr.visitMethodDef(Attr.java:378)
        at com.sun.tools.javac.tree.Tree$MethodDef.accept(Tree.java:443)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:230)
        at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:265)
        at com.sun.tools.javac.comp.Attr.attribClassBody(Attr.java:2263)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2152)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2124)
        at com.sun.tools.javac.comp.Attr.attribClass(Attr.java:2105)
        at com.sun.tools.javac.comp.Attr.visitTypeParameter(Attr.java:2062)
        at com.sun.tools.javac.tree.Tree$TypeParameter.accept(Tree.java:1036)
        at com.sun.tools.javac.comp.Attr.attribTree(Attr.java:230)
        at com.sun.tools.javac.comp.Attr.attribStat(Attr.java:265)
        at com.sun.tools.javac.comp.Attr.attribStats(Attr.java:281)
        at com.sun.tools.javac.comp.Enter$CompleteEnter.complete(Enter.java:1108)
        at com.sun.tools.javac.code.Symbol.complete(Symbol.java:308)
        at com.sun.tools.javac.code.Symbol$ClassSymbol.complete(Symbol.java:571)
        at com.sun.tools.javac.comp.Enter.complete(Enter.java:669)
        at com.sun.tools.javac.comp.Enter.main(Enter.java:648)
        at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:332)
        at com.sun.tools.javac.main.Main.compile(Main.java:523)
        at com.sun.tools.javac.Main.compile(Main.java:41)
        at com.sun.tools.javac.Main.main(Main.java:32)

Rearranging the class declaration to come before its usage works fine:

interface SomeInterface {}
class SomeClass {}
class Foo<T extends SomeClass & SomeInterface> {}
 
public class JSRMultipleTypeBounds {
    public static void main(String[] args) {}
}

Cheers,
Alex.

 

 

Sorry, here is a simpler example demonstrating the crash:

No crash:

interface SomeInterface {}
class SomeClass {}
class Foo<T extends SomeClass & SomeInterface> {}

Crash:

class Foo<T extends SomeClass & SomeInterface> {}
class SomeClass {}
interface SomeInterface {}

Cheers,
Alex.

 

 

I've added this to my list of known prototype bugs:
http://cag.lcs.mit.edu/~cananian/Projects/GJ/
You should probably report this to
jsr14-prototype-comments@sun.com