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 can pass a method as a handler referenced as a delegate, without needing to go thro the trouble of creating a class just because I need to pass a method in Java.

What are the reasons that make it unnecessary (besides citing the clunky use of a brand new class for the purpose) or disadvantageous that Sun decided not to have it in Java? What advantages does creating a class or implementing interfaces anonymously have over delegates? I can't think of any, can you?

Answer 1

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.

Answer 2

Maybe because if a method is to be passed and shared across objects, it shouldn't be owned by one single class. It should probably be shared via its own class. I mean, a transient function does feel a bit odd if you think of it. Bad OO I suppose.

I REALLY like delegates for UI work. It makes window actions so much easier to program.

It may come down to what you think is more negative, a function that has the wrong owner, or (in my case anyway) your code having methods that belong to one class (button clicks, window resize events) not being part of that one class.

Not sure which I prefer.

Answer 3

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 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

For whatever it's worth, I have implemented callback/delegate support in Java using reflection. Details and working source are available on my website.

Answer 6

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.