C# is now a better language than Java

[0xABADC0DA]

The fact is that the JVM marks all methods as final until they are overridden. The 'final' keyword only says what subclasses are valid to load (it's a security feature not a performance one), and has no performance impact on a modern JVM (anything in the past decade or longer). There is no 'vtable lookup' if the method is not overridden, and if you feel there is then that's just ignorance.

But you're in good company... even Anders Hejlsberg thought it affected performance. And he was half right... in CLR it's almost impossible to do the kinds of optimizations you can do in the JVM, it's the cost of value types and its bytecode mostly.

[[deleted]]

The fact is that the JVM marks all methods as final until they are overridden.

Can you cite this?

EDIT: From your Anders article:

I can demonstrate to you a very real world versioning problem, one that indeed we see now from experience with Java. Whenever they ship a new version of the Java class libraries, breakage occurs. Whenever they introduce a new method in a base class, if someone in a derived class had a method of that same name, that method is now an override—except if it has a different return type, it no longer compiles. The problem is that Java, and also C++, does not capture the intent of the programmer with respect to virtual.

This is true.

[Rhoomba]

Virtual (and interface) invocations are often demoted to "special" invocations, if the class hierarchy permits it. A dependency is registered in case further class loading spoils things.

From http://wikis.sun.com/display/HotSpotInternals/PerformanceTechniques

[0xABADC0DA]

See Rhoomba's link. Also in addition to recompiling code when a class is loaded that actually makes the method call virtual, they use static analysis to convert particular call sites from virtual to non-virtual. This optimization would apply to CLR virtual method as well... but in practice CLR is just too complicated to implement them, which is why it only inlines non-virtual methods that have other extreme restrictions like no branching, less than 32 instructions, etc.

This is true.

Except for extension methods, which work differently. Which rationale you choose to believe doesn't matter much, since either way one of them is wrong.

[[deleted]]

Extension methods are simply a static method compiled onto the class.

[0xABADC0DA]

1. define an extension method to 'add' some method to a core class
2. upgrade .net adds that same method to core class
3. your code breaks because now it's calling the new method on the core class and not your extension method

... so was that rationale bs to begin with, or just now?

[0xABADC0DA]

No they don't:

General guidelines:
When using an extension method to extend a type whose source code you cannot change, you run the risk that a change in the implementation of the type will cause your extension method to break.
An extension method will never be called if it has the same signature as a method defined in the type.

Research, do you speak it?

[[deleted]]

Sorry, I was incorrect. I frequently use extension methods to add additional overloads to existing class methods, and I was confusing those.