Not really, no.

You may be able to achieve the same effect by using reflection to get Method objects you can then invoke, and the other way is to create an interface with a single 'invoke' or 'execute' method, and then instantiate them to call the method your interested in (i.e. using an anonymous inner class).

You might also find this article interesting / useful : A Java Programmer Looks at C# Delegates (@blueskyprojects.com)

Depending precisely what you mean, you can achieve a similar effect (passing around a method) using the Strategy Pattern.

Instead of a line like this declaring a named method signature:

// C#public delegate void SomeFunction();

declare an interface:

// Javapublic interface ISomeBehaviour {   void SomeFunction();}

For concrete implementations of the method, define a class that implements the behaviour:

// Javapublic class TypeABehaviour implements ISomeBehaviour {   public void SomeFunction() {      // TypeA behaviour   }}public class TypeBBehaviour implements ISomeBehaviour {   public void SomeFunction() {      // TypeB behaviour   }}

Then wherever you would have had a SomeFunction delegate in C#, use an ISomeBehaviour reference instead:

// C#SomeFunction doSomething = SomeMethod;doSomething();doSomething = SomeOtherMethod;doSomething();// JavaISomeBehaviour someBehaviour = new TypeABehaviour();someBehaviour.SomeFunction();someBehaviour = new TypeBBehaviour();someBehaviour.SomeFunction();

With anonymous inner classes, you can even avoid declaring separate named classes and almost treat them like real delegate functions.

// Javapublic void SomeMethod(ISomeBehaviour pSomeBehaviour) {   ...}...SomeMethod(new ISomeBehaviour() {    @Override   public void SomeFunction() {      // your implementation   }});

This should probably only be used when the implementation is very specific to the current context and wouldn't benefit from being reused.

And then of course in Java 8, these do become basically lambda expressions:

// Java 8SomeMethod(() -> { /* your implementation */ });

Short story: ­­­­­­­­­­­­­­­­­­­no.

Introduction

The newest version of the Microsoft Visual J++ development environmentsupports a language construct called delegates or bound methodreferences. This construct, and the new keywords delegate andmulticast introduced to support it, are not a part of the Java^TMprogramming language, which is specified by the Java LanguageSpecification and amended by the Inner Classes Specification includedin the documentation for the JDKTM 1.1 software.

It is unlikely that the Java programming language will ever includethis construct. Sun already carefully considered adopting it in 1996,to the extent of building and discarding working prototypes. Ourconclusion was that bound method references are unnecessary anddetrimental to the language. This decision was made in consultationwith Borland International, who had previous experience with boundmethod references in Delphi Object Pascal.

We believe bound method references are unnecessary because anotherdesign alternative, inner classes, provides equal or superiorfunctionality. In particular, inner classes fully support therequirements of user-interface event handling, and have been used toimplement a user-interface API at least as comprehensive as theWindows Foundation Classes.

We believe bound method references are harmful because they detractfrom the simplicity of the Java programming language and thepervasively object-oriented character of the APIs. Bound methodreferences also introduce irregularity into the language syntax andscoping rules. Finally, they dilute the investment in VM technologiesbecause VMs are required to handle additional and disparate types ofreferences and method linkage efficiently.