Page 1 of 1
About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sun Jul 28, 2019 10:29 am
by javabean68
Hi,
I have difficulties to understand why the first option doesn't override correctly the given method:
Code: Select all
public <T extends CharSequence> Collection<String> transform(Collection<T> list)
Code: Select all
public Collection<String> transform(Collection<String> list) { return new HashSet<String>(); }; //1
It seems to me that //1 is actually an implementation of the given method with T=String...Is that perhaps the problem? One cannot give an explicit parametrization of a generic method to avoid collisions with the
'compiler-generated' one?
Thanks for any hint
Regards
Fabio
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sun Jul 28, 2019 9:07 pm
by admin
Think about it from the perspective of the user of this method. The base class's method's argument is transform(Collection<T> list), where T extends CharSequence, which means one could pass any CharSequence. So, they could pass a StringBuilder also.
But the subclass method is trying to break the contract by saying it will only accept a String. What if, based on the promise of the base class has code like this:
void methodX(Base b){
Collection<StringBuilder> c = ...;
b.tansform(c);
}
Now, if someone calls methodX with an object of type Derived, what will happen?
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Tue Jul 30, 2019 5:19 am
by javabean68
Ok...and it could not be seen as an overload? The signature is different...
I tried with something like:
Code: Select all
class GenericsFoo {
public <T> void m(T a){
System.out.println("In GenericsFoo " + a);
}
}
public class Generic extends GenericsFoo {
public void m(String a){
System.out.println("In Generics " + a);
}
public static void main(String[] args){
Generic foo = new Generic();
foo.m("Hello!");
}
}
and it gets compiled...What is the difference with the first option...I give an explicit implementation of a generic method...
But the compiler seems not to take this in account
What am I missing?
Thank you very much for your explanation and your Mock: I'm going to take the test tomorrow!
Ciao
Fabio
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Tue Jul 30, 2019 6:09 am
by admin
Please read my explanation again above.
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sun Apr 18, 2021 3:47 am
by dgangan
Hi all,
Could you please advise on following as it's not clear for me:
Why //4 is correct override of transform method?
Code: Select all
class Base{
public <T extends CharSequence> Collection<String> transform(Collection<T> list)
{ return new ArrayList<String>(); } }
Code: Select all
public <T extends CharSequence> Collection<T> transform(List<T> list) { return new HashSet<T>(); }; //4
Overriding method returns type:
Collection<T> which looks to be not covariant with base method return type:
Collection<String>
As for me it looks like return method may return Collection of anything, while base method allows only Collection of String to be returned
Thank you in advance
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sun Apr 18, 2021 11:35 am
by dariusl
dgangan wrote: ↑Sun Apr 18, 2021 3:47 am
Hi all,
Could you please advise on following as it's not clear for me:
Why //4 is correct override of transform method?
I fell for this as well. 4 is an overload, not an override. The option states "//4 correctly overloads the method in Base.". Derived has two "transform" methods in option 4.
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sun Apr 18, 2021 12:00 pm
by dgangan
dariusl wrote: ↑Sun Apr 18, 2021 11:35 am
dgangan wrote: ↑Sun Apr 18, 2021 3:47 am
Hi all,
Could you please advise on following as it's not clear for me:
Why //4 is correct override of transform method?
I fell for this as well. 4 is an overload, not an override. The option states "//4 correctly overloads the method in Base.". Derived has two "transform" methods in option 4.
Yes, i see
overloads word now
Thank you
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Fri Sep 16, 2022 6:17 pm
by cjgiron
Hi Admin,
Can you please explain the line "super is not allowed while defining bounded types" in the explanation about //5?
Code: Select all
public <T super String> Collection<T> transform(List<String> list) {
return new HashSet<T>(); };//5
Why are upper bounds accepted but not lower bounds?
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sun Sep 18, 2022 12:21 am
by admin
If T is a super class of String, then you can't pass List<T> as an argument when argument type is List<String>. (Because, for example, T could be Object and List<Object> will break List<String>).
But if T is a subclass of String you can pass List<T> for List<String>.
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Thu Dec 29, 2022 8:52 am
by aPerson
Hi,
If I do the following:
Code: Select all
class Base {
public <T> Collection<String> transform(Collection<String> list) {
return null;
}
}
class Derived extends Base {
@Override
public <T> Collection<String> transform(Collection list) {
return null;
}
}
it won't compile, but when I remove the <T> from the overriding method, it does compile. Can you please explain why?
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Thu Dec 29, 2022 9:40 am
by admin
The presence of <T> makes the method in the derived class a generic method, which prompts compiler to apply a different set of rules for overriding of generic methods (see the error message generated by the compiler). When there is no <T>, it is not a generic method and the specification allows a generic method to be overridden by a non generic method.
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Thu Dec 29, 2022 9:45 am
by aPerson
Hi, thanks for the reply:) Is the following part of the explanation still correct then?
"Don't get confused by the presence of <T> in the code. The same rules of overriding still apply."
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Thu Dec 29, 2022 10:17 am
by admin
Yes, see the second point in the explanation:
Second, if it is a potential override, check the generic type specification of the parameters. If the overriding method does not use a generic type specification for the parameter type, then it is valid. The reverse is not valid i.e. the overriding method is allowed to erase the generic type specification but is not allowed to add a generic type specification if the overridden method does not have it. If both the methods have a generic type specification, then the specification must match exactly.
I wrote "different" because I was talking about the difference between <T> and no <T>. When you have <T> in both, the same set of rules apply. I know it is a complicated but go through the complete explanation. If you try to pick sentences in isolation, you may feel some things sound contradictory.
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Fri Dec 30, 2022 4:44 pm
by aPerson
Thanks a lot, I think I got it now:) I merged the Second step with the type parameter-part and some new wording to make it clearer for myself. Would this be accurate?
"Second, if it is a potential override, check the generic type specification of the type-parameter(with bounds if any) and actual parameters. If the overriding method does not use a generic type specification in these places, then it is valid. The reverse is not valid i.e. the overriding method is allowed to erase the generic type specification but is not allowed to add a generic type specification if the overridden method does not have it. If both the methods have generic type specification, then the specification must match exactly (this goes for both type-parameter and parameters). For example, if the overridden method has the parameter Set<Integer>, then the overriding method can use Set or Set<Integer>. But if overridden method has Set, then the overriding method must also have Set for a valid override.
The T in <T> is called as the "type" parameter. It is used as a place holder.........etc"
Re: About Question enthuware.ocpjp.i.v11.2.3098 :
Posted: Sat Dec 31, 2022 2:01 am
by admin
Yes, that looks correct.