[swaranga]

There are some edge cases because of which this had to be done, I think. For example calling static methods via the instance variables, the actual method called would be the static type of the variable at compile time and not the actual type at runtime:

    public static void main(String[] args) {
        Parent instance = new Child();

        if (instance instanceof Child p) {
            instance.print(); // prints Parent
            p.print(); // prints Child
        }
    }

    static class Parent {
        static void print() {
            System.out.println("Parent");
        }
    }

    static class Child extends Parent {
        static void print() {
            System.out.println("Child");
        }
    }

Hence, with flow typing, existing code could break in subtle ways.

[smarks]

Several folks have pointed out the poor style in calling static methods using an instance. I think you have a good point, but not a good example. Perhaps a better example is with overload resolution. Consider this Kotlin code:

    fun foo(i: Int) = ...

    fun foo(n: Number) = ...

    fun main() {
        val n: Number = 12;
        foo(n); // calls foo(Number)
        if (n is Int) {
            foo(n); // calls foo(Int)
        }
    }

It's as if smart casting causes the static type of `n` to change in different parts of the main function. As such it also seems to affect overload resolution. Maybe this is exactly what you want. On the other hand it seems like it could lead to some very subtle errors. I'm not a Kotlin programmer, so Kotlin experts please feel free to correct me on details.

[yarg]

Does java provide warnings against calling static methods on Objects?

[smarks]

Yes, if javac is given the `-Xlint:static` option.

[hilbertseries]

If you’re writing code calling static methods on instances of classes, you deserve to have that code broken.

[quantified]

Probably didn’t get written that way but arrived there when that class was refactored somehow.

[recursive]

I've always wondered why that's even allowed.

[_Nat_]

It's actually the default in C#.

This is, in C#, all methods are called according to an object's apparent-type, not its actual-type, by default. To get the Java-behavior, a C#-method would need to be declared `virtual` (or `abstract`), and then more-derived methods would need to choose to `override` them (rather than hide them, often via `new`).

Part of the advantage might be performance. This is, methods that go with the apparent-type don't need to do a virtual-lookup-table resolution, which can save some work in method-calls.

Another advantage is that it can help provide more flexibility in class-hierarchies, since more-derived classes can "hide" less-derived classes' methods without overriding them. It's probably not something that folks really need to do too often, but it's nice to have an easy solution when such a case occurs.

[recursive]

You're talking about virtual vs non-virtual. static is a whole separate thing. static calls are always resolved at build time. You don't even need an instance at all. And probably shouldn't use one.

[_Nat_]

Right -- it's an issue of virtual vs. non-virtual, not static vs. non-static.

For example, [this comment](https://news.ycombinator.com/item?id=31379783 ) provided code showing the issue in this branch of the thread using `static` in Java. Here's the same thing in C# without using `static` (except for `Program.Main()`):

    public class Program
    {
        public static void Main()
        {
            A a = new B();
            
            if (a is B b)
            {
                a.Print();  // Prints "A".
                b.Print();  // Prints "B".
            }
        }
    }
    
    public class A { public void Print() { System.Console.WriteLine("A"); } }
    public class B:A { public new void Print() { System.Console.WriteLine("B"); } }

`static` can work too because it implies non-virtual, but it's not necessary.

Generally speaking, virtual-methods resolve with dependence on the object they're called on since they consult a [virtual-method table](https://en.wikipedia.org/wiki/Virtual_method_table ). Non-virtual methods can resolve without considering the object they're called on (whether static or not) because they call the method that belongs to the apparent-type.

[recursive]

> it's an issue of virtual vs. non-virtual, not static vs. non-static.

That's what you started talking about, but that's not what I'm talking about.

> "calling static methods on instances of classes"

That's from an ancestor, somewhere upthread. Here it is as a c# expression.

    "abc".Format("size: {0}", 7)

Sensibly, c# doesn't allow this, but some languages do. I don't recall which, but I've definitely seen this.

Maybe I'm not understanding a word or something, but the description of the problem is definitely about "static".

[pjmlp]

Influence from OOP languages that preceded Java.

[SemanticStrengh]

How does Kotlin solve those use cases?

> instance.print(); // prints Parent

why? the parent print should be shadowed/overidden by the child bruh

[spullara]

statics don't override

[SemanticStrengh]

oops my bad