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() { @Overridepublic 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.

Have you read this :

Delegates are a useful construct in event-based systems. EssentiallyDelegates are objects that encode a method dispatch on a specifiedobject. This document shows how java inner classes provide a moregeneric solution to such problems.

What is a Delegate? Really it is very similar to a pointer to memberfunction as used in C++. But a delegate contains the target objectalongwith the method to be invoked. Ideally it would be nice to beable to say:

obj.registerHandler(ano.methodOne);

..and that the method methodOne would be called on ano when some specific event was received.

This is what the Delegate structure achieves.

Java Inner Classes

It has been argued that Java provides thisfunctionality via anonymous inner classes and thus does not need the additionalDelegate construct.

obj.registerHandler(new Handler() {public void handleIt(Event ev) {methodOne(ev);}} );

At first glance this seems correct but at the same time a nuisance.Because for many event processing examples the simplicity of theDelegates syntax is very attractive.

General Handler

However, if event-based programming is used in a morepervasive manner, say, for example, as a part of a generalasynchronous programming environment, there is more at stake.

In such a general situation, it is not sufficient to include only thetarget method and target object instance. In general there may beother parameters required, that are determined within the context whenthe event handler is registered.

In this more general situation, the java approach can provide a veryelegant solution, particularly when combined with use of finalvariables:

void processState(final T1 p1, final T2 dispatch) { final int a1 = someCalculation();m_obj.registerHandler(new Handler() {public void handleIt(Event ev) {dispatch.methodOne(a1, ev, p1);}} );}

final * final * final

Got your attention?

Note that the final variables are accessible from within the anonymousclass method definitions. Be sure to study this code carefully tounderstand the ramifications. This is potentially a very powerfultechnique. For example, it can be used to good effect when registeringhandlers in MiniDOM and in more general situations.

By contrast, the Delegate construct does not provide a solution forthis more general requirement, and as such should be rejected as anidiom on which designs can be based.

I know this post is old, but Java 8 has added lambdas, and the concept of a functional interface, which is any interface with only one method. Together these offer similar functionality to C# delegates. See here for more info, or just google Java Lambdas.http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html

No, but they're fakeable using proxies and reflection:

 public static class TestClass {public String knockKnock() {return "who's there?";}}private final TestClass testInstance = new TestClass();@Test public voidcan_delegate_a_single_method_interface_to_an_instance() throws Exception {Delegator<TestClass, Callable<String>> knockKnockDelegator = Delegator.ofMethod("knockKnock").of(TestClass.class).to(Callable.class);Callable<String> callable = knockKnockDelegator.delegateTo(testInstance);assertThat(callable.call(), is("who's there?"));}

The nice thing about this idiom is that you can verify that the delegated-to method exists, and has the required signature, at the point where you create the delegator (although not at compile-time, unfortunately, although a FindBugs plug-in might help here), then use it safely to delegate to various instances.

See the karg code on github for more tests and implementation.

Yes & No, but delegate pattern in Java could be thought of this way. This video tutorial is about data exchange between activity - fragments, and it has great essence of delegate sorta pattern using interfaces.

I have implemented callback/delegate support in Java using reflection. Details and working source are available on my website.

How It Works

There is a principle class named Callback with a nested class named WithParms. The API which needs the callback will take a Callback object as a parameter and, if neccessary, create a Callback.WithParms as a method variable. Since a great many of the applications of this object will be recursive, this works very cleanly.

With performance still a high priority to me, I didn't want to be required to create a throwaway object array to hold the parameters for every invocation - after all in a large data structure there could be thousands of elements, and in a message processing scenario we could end up processing thousands of data structures a second.

In order to be threadsafe the parameter array needs to exist uniquely for each invocation of the API method, and for efficiency the same one should be used for every invocation of the callback; I needed a second object which would be cheap to create in order to bind the callback with a parameter array for invocation. But, in some scenarios, the invoker would already have a the parameter array for other reasons. For these two reasons, the parameter array does not belong in the Callback object. Also the choice of invocation (passing the parameters as an array or as individual objects) belongs in the hands of the API using the callback enabling it to use whichever invocation is best suited to its inner workings.

The WithParms nested class, then, is optional and serves two purposes, it contains the parameter object array needed for the callback invocations, and it provides 10 overloaded invoke() methods (with from 1 to 10 parameters) which load the parameter array and then invoke the callback target.

What follows is an example using a callback to process the files in a directory tree. This is an initial validation pass which just counts the files to process and ensure none exceed a predetermined maximum size. In this case we just create the callback inline with the API invocation. However, we reflect the target method out as a static value so that the reflection is not done every time.

static private final Method COUNT =Callback.getMethod(Xxx.class,"callback_count",true,File.class,File.class);...IoUtil.processDirectory(root,new Callback(this,COUNT),selector);...private void callback_count(File dir, File fil) {if(fil!=null) { // file is null for processing a directoryfileTotal++;if(fil.length()>fileSizeLimit) {throw new Abort("Failed","File size exceeds maximum of "+TextUtil.formatNumber(fileSizeLimit)+" bytes: "+fil);}}progress("Counting",dir,fileTotal);}

IoUtil.processDirectory():

/*** Process a directory using callbacks. To interrupt, the callback must throw an (unchecked) exception.* Subdirectories are processed only if the selector is null or selects the directories, and are done* after the files in any given directory. When the callback is invoked for a directory, the file* argument is null;* <p>* The callback signature is:* <pre> void callback(File dir, File ent);</pre>* <p>* @return The number of files processed.*/static public int processDirectory(File dir, Callback cbk, FileSelector sel) {return _processDirectory(dir,new Callback.WithParms(cbk,2),sel);}static private int _processDirectory(File dir, Callback.WithParms cbk, FileSelector sel) {int cnt=0;if(!dir.isDirectory()) {if(sel==null || sel.accept(dir)) { cbk.invoke(dir.getParent(),dir); cnt++; }}else {cbk.invoke(dir,(Object[])null);File[] lst=(sel==null ? dir.listFiles() : dir.listFiles(sel));if(lst!=null) {for(int xa=0; xa<lst.length; xa++) {File ent=lst[xa];if(!ent.isDirectory()) {cbk.invoke(dir,ent);lst[xa]=null;cnt++;}}for(int xa=0; xa<lst.length; xa++) {File ent=lst[xa];if(ent!=null) { cnt+=_processDirectory(ent,cbk,sel); }}}}return cnt;}

This example illustrates the beauty of this approach - the application specific logic is abstracted into the callback, and the drudgery of recursively walking a directory tree is tucked nicely away in a completely reusable static utility method. And we don't have to repeatedly pay the price of defining and implementing an interface for every new use. Of course, the argument for an interface is that it is far more explicit about what to implement (it's enforced, not simply documented) - but in practice I have not found it to be a problem to get the callback definition right.

Defining and implementing an interface is not really so bad (unless you're distributing applets, as I am, where avoiding creating extra classes actually matters), but where this really shines is when you have multiple callbacks in a single class. Not only is being forced to push them each into a separate inner class added overhead in the deployed application, but it's downright tedious to program and all that boiler-plate code is really just "noise".

It doesn't have an explicit delegate keyword as C#, but you can achieve similar in Java 8 by using a functional interface (i.e. any interface with exactly one method) and lambda:

private interface SingleFunc {void printMe();}public static void main(String[] args) {SingleFunc sf = () -> {System.out.println("Hello, I am a simple single func.");};SingleFunc sfComplex = () -> {System.out.println("Hello, I am a COMPLEX single func.");};delegate(sf);delegate(sfComplex);}private static void delegate(SingleFunc f) {f.printMe();}

Every new object of type SingleFunc must implement printMe(), so it is safe to pass it to another method (e.g. delegate(SingleFunc)) to call the printMe() method.

While it is nowhere nearly as clean, but you could implement something like C# delegates using a Java Proxy.

No, but it has similar behavior, internally.

In C# delegates are used to creates a separate entry point and they work much like a function pointer.

In java there is no thing as function pointer (on a upper look) but internally Java needs to do the same thing in order to achieve these objectives.

For example, creating threads in Java requires a class extending Thread or implementing Runnable, because a class object variable can be used a memory location pointer.

No, Java doesn't have that amazing feature. But you could create it manually using the observer pattern. Here is an example:Write C# delegate in java

The code described offers many of the advantages of C# delegates. Methods, either static or dynamic, can be treated in a uniform manner. The complexity in calling methods through reflection is reduced and the code is reusable, in the sense of requiring no additional classes in the user code. Note we are calling an alternate convenience version of invoke, where a method with one parameter can be called without creating an object array.Java code below:

 class Class1 {public void show(String s) { System.out.println(s); }}class Class2 {public void display(String s) { System.out.println(s); }}// allows static method as wellclass Class3 {public static void staticDisplay(String s) { System.out.println(s); }}public class TestDelegate {public static final Class[] OUTPUT_ARGS = { String.class };public final Delegator DO_SHOW = new Delegator(OUTPUT_ARGS,Void.TYPE);public void main(String[] args) {Delegate[] items = new Delegate[3];items[0] = DO_SHOW .build(new Class1(),"show,);items[1] = DO_SHOW.build (new Class2(),"display");items[2] = DO_SHOW.build(Class3.class, "staticDisplay");for(int i = 0; i < items.length; i++) {items[i].invoke("Hello World");}}}

Java doesn't have delegates and is proud of it :). From what I read here I found in essence 2 ways to fake delegates:1. reflection;2. inner class

Reflections are slooooow! Inner class does not cover the simplest use-case: sort function. Do not want to go into details, but the solution with inner class basically is to create a wrapper class for an array of integers to be sorted in ascending order and an class for an array of integers to be sorted in descending order.