• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Another Question about Generics

 
Ranch Hand
Posts: 146
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all.

Could anybody help me to understand why the returning options commented on doStuff method can't compile when uncommented?
Thanks.


Based on OCP Java SE 6 Programmer Practice Exams by K&B.


 
Bartender
Posts: 15737
368
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Let's say that you have a Hose<Foo>, where Foo is a subtype of Hose.

return e.getE() will not compile, because e might be a Foo<Bar>, where Bar is a subtype of Hose.
In this case, you would be returning a Bar, while the method should return a Foo<Bar>.

return e2 will not compile, because the method should return a Foo, and you're returning a Hose<Foo>.

return new Hose().getE() will not compile, because it returns *some object* that extends Hose, not necessarily a Foo.

You can let the last one compile by properly parameterizing the class:
 
Adolfo Eloy
Ranch Hand
Posts: 146
Eclipse IDE Java Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's still not clear to me.

Considering the code below, when it is executed, the result is:
bar instance
bar instance

for both LINE 1 and LINE 2.
So why LINE 3 can't compile if it is returning the same result?

 
Stephan van Hulst
Bartender
Posts: 15737
368
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The typing system sees that e is a Foo, and e2 is a Hose<Foo>. The method should return a Foo.

LINE 4 works, because e2.getE() returns a Foo, since e2 is a Hose<Foo>.

LINE 3 doesn't work, because e.getE() returns an Object that extends Hose, not necessarily a Foo. This is because e is not parameterized.

You shouldn't use raw types in your program. You'll notice the compiler will warn you about unchecked assignments and conversions.
 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am a little confused as to what the second argument in Hose.doStuff (E e, Hose<E> e2) will accept.

In the example provided in this thread, Hose is instantiated as:

Hose <Foo> h = new Hose <Foo>();

which makes me think that the second argument in doStuff will only take a Hose<Foo> as an argument, but we seem to be passing it a Foo<Bar>.

If someone could explain this, it would be most helpful.

Thanks,

-Matt
 
Matt Gottlieb
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay - I think I get it now. e2's InnerE we know will be of the same type specified in the return, but we can not say the same about e's InnerE. This is due to the fact that we know the generic type E specified in the return type is also the same generic type specified in Hose<E>.
 
If you were a tree, what sort of tree would you be? This tiny ad is a poop beast.
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic