Will upcasting classes affect the method call? Why? Security issues?

Question

Let's have the specified code:

class Foo {
    public void doSomething(){
        System.out.println("Foo");
    }
}
class Bar extends Foo{
    @Override
    public void doSomething(){
        System.out.println("Bar");
    }
}
public class doFoo{
    public static invoke(Foo foo){
        foo.doSomething();
    }
    
    public static void main(String[] args){
        invoke(new Bar()); // Foo or Bar?
    }
}

I tried running the code and the output is:

Bar

Then here's why I get confused.

First if it prints out Bar, and invoke has argument type Foo, why won't print out Foo since it's a Foo typed Object? Since Foo.doSomething() should print out Foo?

Second if this prints out Bar, wouldn't there be some security issues? Let's say there's a private method called writeData(Database database, Data data) method and writeData(Data data) calling it. Or as the follows:

public void writeData(Data data){
    writeData(DEFAULT_DATABASE != null ? DEFAULT_DATABASE : initializeDatabaseAndGet();
}
private void writeData(Database database, Data data){
    // Idk what to write...
}

In this I could invoke writeData using Reflection and my custom implementation of Database. With my implementation sending passwords/tokens and things to hack into the database?

Am I misunderstanding things here?

If it didn't work that way, `Object.toString()` would be the only `toString()` - do you think that would be good? Why not? BTW, `private` methods are not inherited. So that's even less relevant. — Elliott Frisch, Mar 21 '23 at 23:52
When I say "acrastt, state your name", you would say "acrastt". When I look at you and say "human, state your name", would you then say "human" or "acrastt"? This behaviour is what polymorphism is all about. — Tom, Mar 21 '23 at 23:54

score 2 · Answer 1 · answered Mar 22 '23 at 01:36

since it's a Foo typed Object

This is the heart of your misconception. I assume you said it's 'Foo type' because of the 'Foo foo' declaration.

The object is actually a Bar. It was created by new Bar(). The object is really, and will be for as long as it exists, a Bar.

A Bar is also a Foo, of course - that it what inheriting from Foo means. Nevertheless, its behaviour is that of a Bar.

You have a number of Foo variables - that is, variables that can contain a reference to a Foo object. But the variable being a Foo variable does not make the Bar-ness of the actual object go away.

David Ruiz · Answer 2 · 2023-03-22T14:58:26.080

This is called polymorphism.

It requires 3 things to activate: 1.Upcasting 2.Inheritance 3.Method overriding.

Looking at your example you can find all 3 things are present:

Upcasting is happening when invoke(Foo foo) takes Bar as input. The method recognizes this as a Foo object even though it stores a child of Foo.
Inheritance is present since Bar is inheriting Foo.
Method overriding is present because the method doSomething() has the same method signatuee for both Foo and Bar.

Finally, this means that Java will let polymorphism take effect and the method that will be called is that of the child (Bar) and not that of Foo.

Regarding your question on security, notice that the two methods you wrote writeData don't have the same signature. Additionally, you cannot override private methods in Java. These are two of the conditions of polymorphism to kick in. For those reasons it seems like your function is secure.

I have never heard the term "confusing casting" before in this context, it is definitely not normal terminology related to polymorphism. — Mark Rotteveel, Mar 22 '23 at 08:43
Upcasting is the appropriate term, confusing casting is just a an easy way to remember that it is an object being confusely passed as a parent element instead of itself. Learned it this way back in my java class. — David Ruiz, Mar 22 '23 at 14:59

Will upcasting classes affect the method call? Why? Security issues?

2 Answers2