Win a copy of Clojure in Action this week in the Clojure forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

subtype not allowed in implementation of generic interface

 
Ben Ooms
Ranch Hand
Posts: 47
Debian Eclipse IDE Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello all,

I have a question regarding generics i cannot find a answer to it. I have a generic interface looking like:



with a implementation looking like:


Category extends Model. My question is: When I try to change the method to the compiler throws a error:

build:
[javac] Compiling 1 source file to C:\playground\cashtrackerscratchbook\build
[javac] C:\playground\cashtrackerscratchbook\src\nl\benooms\model\CategoryDao.java:10: nl.benooms.model.CategoryDao is not abstract and does not override abstract method <T>create(T) in nl.benooms.model.Dao
[javac] public class CategoryDao implements Dao{
[javac] ^
[javac] Note: C:\playground\cashtrackerscratchbook\src\nl\benooms\model\CategoryDao.java uses unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 error

I taught that <? extends Model> let me choose a subtype parameter like the subtype return in the method retreave. Is this wrong thinking ?

 
Harsha Smith
Ranch Hand
Posts: 287
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Generics Type Erasure issue???
 
Matthew Brown
Bartender
Posts: 4549
8
Java Netbeans IDE Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Ben. Welcome to the Ranch!

If your code was allowed, what would you expect to happen in the following situation?

That would compile - the argument is allowable as far as the method declared in Dao is concerned. But CategoryDao doesn't have a method that will accept that argument, so we've got a problem.

Whenever you override a method, you have to do it with the "same" argument types. When you're talking about generics, "same" means "have the same erasure" - remember that generics don't exist an run-time, so the generic type has to be "erased" to a specific type. The erasure of T extends Model is Model, which means your first implementation is fine but your second isn't.

Does that help?


 
Harsha Smith
Ranch Hand
Posts: 287
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
is this bad?
 
Matthew Brown
Bartender
Posts: 4549
8
Java Netbeans IDE Scala
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Harsha Smith wrote:

Well, I don't think it's great design. I'd prefer trying to make the original Dao generic.

Note that I haven't tested this, so there may be errors:
And then you can always have a CategoryDao implements Dao<Category>, if you want a category-specific subclass.
 
Ben Ooms
Ranch Hand
Posts: 47
Debian Eclipse IDE Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:Hi Ben. Welcome to the Ranch!

If your code was allowed, what would you expect to happen in the following situation?

That would compile - the argument is allowable as far as the method declared in Dao is concerned. But CategoryDao doesn't have a method that will accept that argument, so we've got a problem.

Whenever you override a method, you have to do it with the "same" argument types. When you're talking about generics, "same" means "have the same erasure" - remember that generics don't exist an run-time, so the generic type has to be "erased" to a specific type. The erasure of T extends Model is Model, which means your first implementation is fine but your second isn't.

Does that help?




Hi Matthew,

Thanks for the explanation, now I understand why it cannot and shoulden work. I'm working with generics for the first time while studying for SCJP

regoards,
Ben
 
Ben Ooms
Ranch Hand
Posts: 47
Debian Eclipse IDE Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Matthew Brown wrote:
Harsha Smith wrote:

Well, I don't think it's great design. I'd prefer trying to make the original Dao generic.

Note that I haven't tested this, so there may be errors:
And then you can always have a CategoryDao implements Dao<Category>, if you want a category-specific subclass.


Hi Matthew,

I wanted a category specific subclass and changed Dao like your code(and Category class declaration with <Category>) and its working as I wanted except for the create method. The nasty ;<) compiler complaints about not implementing the abstract method public T create (Model Model).

So this throws the compiler error:


but this compile fine:


the class declaration of Category is:
 
I agree. Here's the link: http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic