Why doesn't Java have method delegates?

问题:

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?

回答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.

回答2:

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

回答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)

回答4:

java does not have closures because it was not intended to be a functional language, but an object oriented one.
as in many case you can fake another language paradigm, in this case using anonymous interfaces instead of closures.
but now things are changing and under the pressure of new jvm languages like scala, groovy, jruby, etc., that combines oo and funcional paradigms, the java committee is trying to put closures into java 7.

回答5:

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.

回答6:

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

回答7:

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.

回答8:

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

回答9:

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.