We Keep Coding

Overriding a method which has a parameter of the abstract base class

So, the problem is:
I have an abstract base class (Property) which has an abstract member method (same()). The same() method returns boolean and should check for equality, but "equality" may be interpreted differently in the subclasses, therefore I am not overriding equals() or compareTo(). Because it tests for equality with another object of its type, the signature looks like that:
public abstract boolean same(Property other);
Now, when I am trying to override it in class, let's say "SubProperty", i cannot use SubProperty as the type of the parameter. I know about the reasons of this in general and the recommendation to add type bounds, but things are getting more complicated because the parameter type is its own class.
Is there any smooth way to override the method properly?
Because it was recommended in other StackOverflow questions, I tried to use type bounds (which are in this case circular). So, the class would look like this:
public abstract class Property<T extends Property<T>>
and the same() method:
public abstract boolean same(T other);
For the subclass this means:
public class SubProperty extends Property<SubProperty>
and the same()method:
public boolean same(SubProperty other);
This would be the result if I would use type bounds as recommended. It actually builds, but I don't even know if it would work properly. Anyway, it looks horrible and unmaintainable (especially because I am using 2 other generic type arguments in Property).
I hope that there is some other way to do this. If it matters, I am using java 1.8 (openjdk 1.8.0.212-b04)
EDIT 1:
Because people asked: same() is not anything like equals() or compareTo(). Yes, it is about equality in some sense. But actually I think it is easier to describe it like this:
same() is a method that checks for something in this and some other object of the same class and returns true or false according to what happened in the method.
EDIT 2:
As #davidxxx explained, it seems to be impossible to make the code any "smoother". I will probably just leave the base class parameter and check which object I got inside the method. Seems not too bad after all.

Unfortunately you don't have other ways because in Java the return type is covariant but the parameter type is not because it would be contrary to the liskov principle.
Liskov's notion of a behavioural subtype defines a notion of
substitutability for objects; that is, if S is a subtype of T, then
objects of type T in a program may be replaced with objects of type S
without altering any of the desirable properties of that program (e.g.
correctness).
Here is a simple example that shows why this rule matters.
Suppose the subclass :
public class FooProperty extends Property{
public boolean same(FooProperty other){...}
}
Suppose that you instantiate it in this way :
Property property = new FooProperty();
You can so do :
property.same(new FooProperty());
But you can also do :
property.same(new Property());
But that is not consistent in terms of expected parameter for the FooProperty.same() override that expects a FooProperty.
And that violates the liskov principle because I should be able to replace any Property instance by any subclass of that.
Only, the generic type declared on the class as in your example allows to bypass this limitation and to leave the subclass makes its mind about the subclass to use as parameter.
Anyway, it looks horrible and unmaintainable
That is very maintainable since if you refactor the class name, it will be updated.
But that is a little verbose indeed.

I think you'd just use a generic
public abstract class AbstractBase<T extends Property> {
public abstract boolean same(T property):
}
public class Concrete extends AbstractBase<SubProperty> {
public boolean same(SubProperty property) {
// TODO
}
}

Java generic type comparison

I'd like to know if something like this is possible in Java (mix of C++ and Java ahead)
template<typename T> bool compare(Wrapper wrapper) {
if(wrapper.obj.getClass().equals(T.class))
return true
return false
}
To clarify, the function takes in an object which contains a java.lang.object, but I'd like to be able to pass that wrapper into this generic comparison function to check whether that object is of a particular type, ie
if(compare<String>(myWrapper))
// do x

No, it's not possible due to erasure. Basically, the compare method has no idea what T is. There's only one compare method (as opposed to C++, where there's one per T), and it isn't given any information about how it was invoked (ie, what the caller considered its T to be).
The typical solution is to have the class (or method) accept a Class<T> cls, and then use cls.isInstance:
public <T> boolean compare(Wrapper wrapper, Class<T> cls) {
return cls.isInstance(wrapper.obj);
}
// and then, at the call site:
if (compare(wrapper, Foo.class)) {
...
}
Of course, this means that the call site needs to have the Class<T> object. If that call site is itself a generic method, it needs to get that reference from its caller, and so on. At some point, somebody needs to know what the specific type is, and that somebody passes in Foo.class.

You cannot reference static members of a type parameter (such as you try to do in the form of T.class). You also cannot use them meaningfully in instanceof expressions. More generally, because Java generics are implemented via type erasure, you cannot use type parameters in any way at run time -- all type analysis is performed statically, at compile time.
Depending on exactly what you're after, there are at least two alternative approaches.
The first, and more usual, is to ensure that the necessary types can be checked statically. For example, you might parameterize your Wrapper class with the type of the object it wraps. Then, supposing that you use it in a program that is type-safe, wherever you have a Wrapper<String> you know that the wrapped object is a String.
That doesn't work so well if you want to verify the specific class of the wrapped object, however, when the class to test against is not final. In that case, you can pass a Class object, something like this:
<T> boolean compare(Wrapper<? super T> wrapper, Class<T> clazz) {
return wrapper.obj.getClass().equals(clazz);
}
That checks the class of the wrapped object against the specified class, allowing the method to be invoked only in cases where static analysis allows that it could return true.
You can actually combine those two approaches, if you like, to create a Wrapper class whose instances can hold only members of a specific class, as opposed to any object that is assignable to a given type. I'm not sure why you would want to do that, though.

Why is this overloading wrong? [duplicate]

Why is it not legal to have the following two methods in the same class?
class Test{
void add(Set<Integer> ii){}
void add(Set<String> ss){}
}
I get the compilation error
Method add(Set) has the same erasure add(Set) as another method in type Test.
while I can work around it, I was wondering why javac doesn't like this.
I can see that in many cases, the logic of those two methods would be very similar and could be replaced by a single
public void add(Set<?> set){}
method, but this is not always the case.
This is extra annoying if you want to have two constructors that takes those arguments because then you can't just change the name of one of the constructors.

This rule is intended to avoid conflicts in legacy code that still uses raw types.
Here's an illustration of why this was not allowed, drawn from the JLS. Suppose, before generics were introduced to Java, I wrote some code like this:
class CollectionConverter {
List toList(Collection c) {...}
}
You extend my class, like this:
class Overrider extends CollectionConverter{
List toList(Collection c) {...}
}
After the introduction of generics, I decided to update my library.
class CollectionConverter {
<T> List<T> toList(Collection<T> c) {...}
}
You aren't ready to make any updates, so you leave your Overrider class alone. In order to correctly override the toList() method, the language designers decided that a raw type was "override-equivalent" to any generified type. This means that although your method signature is no longer formally equal to my superclass' signature, your method still overrides.
Now, time passes and you decide you are ready to update your class. But you screw up a little, and instead of editing the existing, raw toList() method, you add a new method like this:
class Overrider extends CollectionConverter {
#Override
List toList(Collection c) {...}
#Override
<T> List<T> toList(Collection<T> c) {...}
}
Because of the override equivalence of raw types, both methods are in a valid form to override the toList(Collection<T>) method. But of course, the compiler needs to resolve a single method. To eliminate this ambiguity, classes are not allowed to have multiple methods that are override-equivalent—that is, multiple methods with the same parameter types after erasure.
The key is that this is a language rule designed to maintain compatibility with old code using raw types. It is not a limitation required by the erasure of type parameters; because method resolution occurs at compile-time, adding generic types to the method identifier would have been sufficient.

Java generics uses type erasure. The bit in the angle brackets (<Integer> and <String>) gets removed, so you'd end up with two methods that have an identical signature (the add(Set) you see in the error). That's not allowed because the runtime wouldn't know which to use for each case.
If Java ever gets reified generics, then you could do this, but that's probably unlikely now.

This is because Java Generics are implemented with Type Erasure.
Your methods would be translated, at compile time, to something like:
Method resolution occurs at compile time and doesn't consider type parameters. (see erickson's answer)
void add(Set ii);
void add(Set ss);
Both methods have the same signature without the type parameters, hence the error.

The problem is that Set<Integer> and Set<String> are actually treated as a Set from the JVM. Selecting a type for the Set (String or Integer in your case) is only syntactic sugar used by the compiler. The JVM can't distinguish between Set<String> and Set<Integer>.

Define a single Method without type like void add(Set ii){}
You can mention the type while calling the method based on your choice. It will work for any type of set.

It could be possible that the compiler translates Set(Integer) to Set(Object) in java byte code. If this is the case, Set(Integer) would be used only at compile phase for syntax checking.

I bumped into this when tried to write something like:
Continuable<T> callAsync(Callable<T> code) {....}
and
Continuable<Continuable<T>> callAsync(Callable<Continuable<T>> veryAsyncCode) {...}
They become for compiler the 2 definitions of
Continuable<> callAsync(Callable<> veryAsyncCode) {...}
The type erasure literally means erasing of type arguments information from generics.
This is VERY annoying, but this is a limitation that will be with Java for while.
For constructors case not much can be done, 2 new subclasses specialized with different parameters in constructor for example.
Or use initialization methods instead... (virtual constructors?) with different names...
for similar operation methods renaming would help, like
class Test{
void addIntegers(Set<Integer> ii){}
void addStrings(Set<String> ss){}
}
Or with some more descriptive names, self-documenting for oyu cases, like addNames and addIndexes or such.

In this case can use this structure:
class Test{
void add(Integer ... ii){}
void add(String ... ss){}
}
and inside methods can create target collections
void add(Integer ... values){
this.values = Arrays.asList(values);
}

Java Generics, Type Inference, Inheritance?

I'm reading about type inference for generics, and this code was provided as an example that fails to compile.
import java.io.*;
class LastError<T> {
private T lastError;
void setError(T t){
lastError = t;
System.out.println("LastError: setError");
}
}
class StrLastError<S extends CharSequence> extends LastError<String>{
public StrLastError(S s) {
}
void setError(S s){
System.out.println("StrLastError: setError");
}
}
class Test {
public static void main(String []args) {
StrLastError<String> err = new StrLastError<String>("Error");
err.setError("Last error");
}
}
And the explanation given in the book was:
"(It looks like the setError() method in StrLastError is overriding setError() in the LastError class. However, it is not the case. At the time of compilation, the knowledge of type S is not available. Therefore, the compiler records the signatures of these two methods as setError(String) in superclass and setError(S_extends_CharSequence) in subclass—treating them as overloaded methods (not overridden). In this case, when the call to setError() is found, the compiler finds both the overloaded methods matching, resulting in the ambiguous method call error."
I really don't understand why type S can't be inferred at compile time.
String is passed when invoking the constructor of class StrLastError,
and from the API docs, String does implement interface CharSequence,
so doesn't that mean that S for <S extends CharSequence> actually is of type String?
I've read the Java online tutorial on the topic of generics several times. I've checked "Type Inference", and Inheritance, I just don't know how the whole thing works. I really need an explanation on this question.
The points I'm stuck at are:
If the subtype can't decide S, how come the super type can decide T, because the superclass does not have an upper bound? Or does it infer that T is String because the subtype calls the supertype's constructor first?
I understand that if the Constructor is invoked as:
StrLastError<CharSequence> err = newStrLastError<>((CharSequence)"Error");
there will be no ambiguity, since it's plain method overriding then. (Or am I even wrong here?)
However, like I said in the beginning, if String is passed, why can't S be inferred to be String?

You have to remind yourself that the classes are compiled one by one. Java generics are not templates as in other languages. There will only be one compiled class and not one class per type it is used with.
This way you can see that the class StrLastError will need to be compiled in a way such that it can also be used with other classes implementing CharSequence as generic type S.
Thats why the compiler gets you two different methods instead of an overridden one. Now it would be a runtime-job to see that the subclass may have wanted to override the method in the parent just in those cases where the types suggest it. Since this behaviour is hard to understand for the developer and would possibly lead to programming mistakes, it raises an exception.
If you use CharSequence as the generic type parameter of the class StrLastError, you will call the setError method in the parent class, since the type of "Last Error" is String, which is more specific than CharSequence and Java always chooses the most specific method in case it is overloaded. (I hope it is clear the the method was not overridden in this case either)

If the subtype can't decide S, how come the super type can decide T, because the superclass does not have an upper bound? Or does it infer that T is String because the subtype calls the supertype's constructor first?
The super type isn't deciding or inferring what T is; you're explicitly telling it what T is by this declaration:
class StrLastError<S extends CharSequence> extends LastError<String>
T is now bound to String for LastError, which makes every reference to T in the parent class a concrete String.
Your child class now has a bound S extends CharSequence attached to it, but this is independent to the bounds applied to the parent class.
What happens now is that Java will compile your child class, and the result of your child class is that two methods with a signature that matches String will be created. (Key note here: A String is-a CharSequence.)
In your child class, setError(Ljava/lang/CharSequence;)V is generated as the signature for setError. Because of the way generics work, LastError#setError will be treated as if it has a signature of setError(Ljava/lang/String;)V. This is also why when you go to actually override the method, it will place a String type as your parameter instead of anything else.
So, what we arrive at are two methods that have override-equivalent signatures.
void setError(CharSequence s)
void setError(String s)
JLS 8.4.8.4. applies here.
It is possible for a class to inherit multiple methods with
override-equivalent signatures (§8.4.2).
It is a compile-time error if a class C inherits a concrete method
whose signature is a subsignature of another concrete method inherited
by C. This can happen if a superclass is generic, and it has two
methods that were distinct in the generic declaration, but have the
same signature in the particular invocation used.
I understand that if the Constructor is invoked as StrLastError err = new StrLastError<>((CharSequence)"Error"); there will be no ambiguity, since its plain method overriding then.(Or I'm even wrong here)
No, now you're messing with raw types. Interestingly enough it will work, primarily because the signatures for the two methods has become:
void setError(Object s)
void setError(String s)
You want to use generics to avoid a scenario like this; you may want to invoke the super class method at some point, but in this scenario with these bindings, it's very difficult to accomplish.

This is a tricky example, to fix it you need to change the following line:
class StrLastError<S extends CharSequence> extends LastError<S>

What is the reasoning behind not allowing supertypes on Java method overrides?

The following code is considered invalid by the compiler:
class Foo {
void foo(String foo) { ... }
}
class Bar extends Foo {
#Override
void foo(Object foo) { ... }
}
I think that this is described in the JLS 8.4.8.1: "The signature of m1 is a subsignature (§8.4.2) of the signature of m2." and in 8.4.2: "the bounds of corresponding type variables are the same".
My question is: why can't the parameter in the subtype (Bar) be a supertype of the parameter in the supertype (Foo). In the example Object is a supertype of String. As far as I can see allowing this wouldn't violate the Liskov Substitution Principle.
Is there a scenario in which allowing this would break the code or is it a limitation of the current JLS?

Suppose you could do that. Now your superclass looks like this:
class Foo {
void foo(String foo) { ... }
void foo(Number foo) { ... }
}
and your subclass now:
class Bar extends Foo {
#Override
void foo(Object foo) { ... }
}
The language probably could allow such a thing (and just dispatch both Foo.foo(String) and Foo.foo(Number) to Bar.foo(Object)), but apparently the design decision for Java here is that one method only can override exactly one other method.
[Edit]
As dasblinkenlight said in his answer, one can have a foo(Object) without the #Override, but this just overloads the foo functions, and does not override them. When calling, java chooses the most specific method, so foo("Hello World") would always get dispatched to the foo(String) method.

(A rewrite, from a different angle ... my original answer contained an error. :( )
why can't the parameter in the subtype (Bar) be a supertype of the parameter in the supertype (Foo).
I believe that technically it could, and it wouldn't break ancestor contracts following type substition (Liskov Substitution Principle).
Types are passed-by-value (including reference types).
The caller can never be forced to deal with different parameter types than what it passes in.
A method body can swap a parameter type, but can't return it back to the caller (no such thing as 'output parameter types').
If your proposal was allowed, and a call was made to the ancestor method signature, a decendent class could override the method with broader types, but it's still impossible to return a broader type than what the caller sets.
The override could never break a client that uses the narrow ancestor method contract.
From my analysis below, I surmise/guess the rationale for not allowing your scenario:
Performance-related: allowing broader types in override would impact runtime performance, a major issue
Functionality-related: it only adds a minor amount of functionality. As it stands, you could add your 'broader method' as an overloaded method without overriding. Then you could additionally override the original method with an exact signature match. The net result: you achieve something quite similar, functionally.
Compiler Requirements for Method Override - JLS 7
The compiler's required to act accordancing to your experience. 8.4 Method Declarations:
A method in a subclass can override a method in an ancestor class iff:
the method names are identical (8.4.2 and 8.4.8.1)
the method parameters have identical types, after erasure of generic type parameters (8.4.2 and 8.4.8.1)
the return type is type-substitutable for the return type in the ancestor class, i.e. the same type or narrower (8.4.8.3)
Note: subsignature does not mean the overriding method uses subtypes of the overridden method. The overriding method is said to have a subsignature of the overridden method when the overriding method has exactly the same type signature except that generic types and the corresponding raw types are considered equivalent.
Compiler v Runtime Processing for Method Matching & Invocation
There's a performance hit matching method signatures via polymorphic type matching. By restricting override method signatures to exact match of ancestor, the JLS moves much of this processing to compile time. 15.12 Method Invocation Expressions - summarised:
Determine Class or Interface to Search (Compile-Time Determination)
Obtain the base type T, on which the method is being invoked.
This is the reference type declared to the compiler and not the runtime type (where a subtype may be substituted).
Determine Method Signature (Compile-Time Determination)
Search the compile-time base type T, for applicable methods matching the name and parameter & return types consistent with the call.
resolve generic parameters for T, either explicitly passed or implicitly inferred from the types of invocation method arguments
stage 1: methods applicable via consistent types/subtypes ('subtyping')
stage 2: methods applicable via automatic boxing/unboxing plus subtyping
stage 3: methods applicable via automatic boxing/unboxing plus subtyping plus variable 'arity' parameters
determine the most specific matching method signature (i.e. the method signature that could successfully be passed to all other matching method signatures); if none: compiler/ambiguity error
Check: Is the Chosen Method Appropriate? (Compile-Time Determination)
Evaluation of Method Invocation (Runtime Determination)
Determine runtime target reference type
Evaluate arguments
Check accessibility of method
Locate method - an exact signature match against the compile-time matched signature
Invoke
Performance Hit
The breakdown, in terms of text in the JLS:
Step 1: 5%
Step 2: 60%
Step 3: 5%
Step 4: 30%
Not only is Step 2 volumous in text, it's surprisingly complex. It has complex conditions and many expensive test conditions/searches. It's advantageous to maximise the compiler's execution of the more complex and slower processing here. If this was done at runtime, there would be a drag on performance, because it would occur for each method invocation.
Step 4 still has significant processing, but it is as streamlined as possible. Reading through 15.12.4, it contains no processing steps that could be moved to compile time, without forcing the runtime type to exactly match the compile-time type. Not only that, but it does a simple exact match on the method signature, rather than a complex "ancestor type match"

Java annotations cannot change the way the compiler generates byte code from your classes. You use annotations to tell the compiler how you think your program should be interpreted, and report errors when compiler's interpretation does not match your intentions. However, you cannot use annotations to force the compiler to produce code with different semantics.
When your subclass declare a method with the same name and parameter count as in its superclass, Java must decide between two possibilities:
You want the method in the subclass to override the method in the superclass, or
You want the method in the subclass to overload the method in the superclass.
If Java allowed foo(Object) to override foo(String) the language would have to introduce an alternative syntax for indicating an intent to overload a method. For example, they could have done it in a way similar to C#'s new and override in method declarations. For whatever reason, however, the designers decided against this new syntax, leaving the language with the rules specified in JLS 8.4.8.1.
Note that the current design lets you implement the functionality of an override by forwarding the call from the overloaded function. In your case, that would mean calling Bar.foo(Object) from Foo.foo(String) like this:
class Foo {
public void foo(String foo) { ... }
}
class Bar extends Foo {
#Override
public void foo(String foo) { this.foo((Object)foo); }
public void foo(Object foo) { ... }
}
Here is a demo on ideone.

The answer is plain simple, in Java, for method overriding, you must have the exact signature of the super type. However, if you remove the #Override annotation, your method would be overloaded and your code won't break. This is a Java implementation that ensures that you mean the method implementation should override the implementation of the super type.
Method overriding works in the following way.
class Foo{ //Super Class
void foo(String string){
// Your implementation here
}
}
class Bar extends Foo{
#Override
void foo(String string){
super(); //This method is implied when not explicitly stated in the method but the #Override annotation is present.
// Your implementation here
}
// An overloaded method
void foo(Object object){
// Your implementation here
}
}
The methods shown above are both correct and their implementation can vary.
I hope this helps you.

To answer the question in the title of the post What is the reasoning behind not allowing supertypes on Java method overrides?:
The designers of Java wanted a simple object oriented language and they specifically rejected features of C++ where, in their opinion, the complexity/pitfalls of the feature wasn't worth the benefit. What you describe may have fallen into this category where the designers chose to design/specify out the feature.

The problem with your code is that you are telling compiler that foo method in Bar class is overridden from parent class of Bar, i.e. Foo. Since overridden methods must have same signature, but in your case, according to syntax it is an overloaded method as you have changed the parameter in foo method of Bar class.

If you can override with superclasses, why not with subclasses as well?
Consider the following:
class Foo {
void foo(String foo) { ... }
}
class Bar extends Foo {
#Override
void foo(Object foo) { ... }
}
class Another extends Bar {
#Override
void foo(Number foo) { ... }
}
Now you have succesfully overriden an method whose original parameter was a String to accept a Number. Inadvisable to say the least...
Instead, the intended results may be replicated by using overloading and the following, more explicit, code:
class Foo {
void foo(String foo) { ... }
}
class Bar extends Foo {
#Override
private void foo(String foo) { ... }
void foo(Object foo) { ... }
}
class Another extends Bar {
#Override
private void foo(Object foo) { ... }
void foo(Number foo) { ... }
}