Why doesn't Java have method delegates?

Question

The Java gurunaths (natha नाथ = sanskrit for deity-master-protector) at Sun should condescend to accept the necessity of delegates and draft it into Java spec.

In C#, I

Answer 1

Here is Tom Ball's account for Microsoft proposal to add them to Java and why Sun rejected them.

IMO, Java should have had closures twelve years back. Gilad Bracha argued for closures and no one listened. In his own words:

I personally argued for adding closures since 1997/98. My blood pressure still rises measurably when I recall the response I got at the time: "Our customers aren't asking for it, so why add it?".

Sad, but true.

Answer 2

Because, they thought that:

Bound method references [delegates] are simply unnecessary. [...] Moreover, they detract from the simplicity and unity of the Java language. Bound method references are not the right path for future language evolution.

Taken from this ( old ) white paper:

http://java.sun.com/docs/white/delegates.html

Now Java is considering adding them, once the language have evolved enough. I'm pretty sure they will be in the language soon ( at least sooner than Perl 6 :P )

You can also use: Software Monkey Callback method

Answer 3

In Java, you have inner classes, which are tied to one particular instance of the parent class and have direct access to its members. Thus, implementing an inner class does not require (much) more code than writing a method.

C# does not have inner classes. Both inner classes (like in Java) and delegates (like in C#) have their advantages (sometimes I miss inner classes in C#), but from a language designer point of view it makes sense to stick to either one of them (rather than supporting both), since this makes the class library design more consistent.

Answer 4

[Minor edits]

Let me first say that I'm not against or in favor of adding delegates to Java. I'm just explaining the background.

First, Sun's Java team has been traditionally more conservative (compared to the C# team) regarding evolution of the language.

Second, Adding a delegate construct into Java would probably require the introduction of a new keyword, such as: "delegate". This will break existing code in which there are variables named "delegate".

Third, there is this design principle called the "Single Choice Principle" http://en.wikipedia.org/wiki/Single_choice_principle. When applied to language design it means that a programmer should have only one obvious way to achieve something. Or, in other words, multiple choices are risky. The introduction of delegates into Java will work against this principle as their behavior can be achieved via anonymous classes.

[Of course, this principle should not be taken literally. If it were then we'd be programming with a good old Turing Machine. I guess the Sun guys felt that delegates do not constitute a benefit that outweighs the single choice violation]

Answer 5

Simplicity.

By not introducing the concept of delegates into Java, they made the language simpler. Just like not having properties, indexers, ....

(using a simpler language is not necessarily simpler by the way; probably they should have added delegates but that's not how they made the design decisions)

Answer 6

Delegates in C# look ugly to me. (declaring something as variable, and then adding () after it feels bad in OOP)

Besides, if you want : "The delegate object can then be passed to code which can call the referenced method, without having to know at compile time which method will be invoked.

you can simply use java.lang.reflect.Method

Edit: As you said, using reflection is not a good approach. This is true, but using delegates, in an OOP perspective, is not a better approach, in my opinion. It is a functional-language construct.