안드로이드+잡탕 블로그

https://roshanfonseka.wordpress.com/2016/03/06/a-taste-of-manualresetevent-for-java/

https://github.com/roshfsk/Java-ManualResetEvent/blob/master/src/com/devthread/manualreseteventdemo/ManualResetEvent.java

http://docs.oracle.com/javase/6/docs/api/java/util/Observable.html

An Observable object has a list of observers which implement the Observer interface, and mechanisms for adding and removing observers. If o.notifyObservers(x) is called on the observable, update(o,x) will be called on each observer. This mechanism is somewhat old fashioned and rarely used in new code - it dates from Java 1.0 before EventObject was added in Java 1.1 and better event handling added for AWT and beans.

------------------------------------

https://scatteredcode.wordpress.com/2011/11/24/from-c-to-java-events/

Events in C#

The first conceptual hurdle I came across was dealing with Events. In C#, events are pretty easy to deal with, as an event is can be described as a collection of methods that all conform to a single delegate’s method signature. An example of this, based on a good tutorial on Code Project is:

This is essentially adding the HeardIt method to the Metronome.Tick event, so whenever the event is fired, it calls theTest.HeardIt() method (along with any other method attached to the event). This is pretty straightforward in my (biased) opinion.

Events In Java

I started reading some pages on the net about how events in Java are handled. The first few articles I came across were kind of confusing and all over the place. I felt like I almost understood how it’s done but I was missing one piece of crucial information that binds it all together for me. After reading a few more articles, I finally had my “Ah ha!” moment, and it all clicked.

The confusion was due to that fact that unlike in C#, there is no event keyword in Java. In fact, and this is the piece I was missing, there essentially is no such thing as an event in Java. In Java you are essentially faking events and event handling by using a standard set of naming conventions and fully utilizing object-oriented programming.

Using events in java is really just a matter of defining an interface that contains a method to handle your event (this interface is known as the listener interface). You then implement this interface in the class that you want to handle the event (this is the listener class). In the class that you wish to “fire off” the event from you maintain a collection of class instances that implements the listener interface, and provide a method so listener classes can pass an instance of themselves in to add and remove them from the collection. Finally, the act of firing off events is merely going through the collection of listener classes, and on each listener call the listener interface’s method. It’s essentially a pure-OOP solution masquerading as an event handling system.

To see this in action, let’s create the equivalent of the C# event example in Java.

When the app starts (and enters the MainApp’s main() method), it creates the event source and tells it that the MainApp class should be registered as a listener for the Metronome event. When the event source class starts, it will “fire” off the event by just looking at all classes registered that implement the MetronomeEvent interface, and call the Tick() method for that implemented class.

No special magic, just pure object-oriented programming!

In Java 8, the code can be simplified using the lambda, streams, and pipeline features:

if (_listeners != null && _listeners.isEmpty())
{
Enumeration e = _listeners.elements();
while (e.hasMoreElements())
{
MetronomeEvent e = (MetronomeEvent)e.nextElement();
e.Tick(new Date());
}
}

can be changed to

if (_listeners != null)
{
_listeners.parallelStream().forEach(ell -> ell.Tick(new Date()));
}

-------------------------------------

---------------------------------------

-----------------------------------------

--------------------------------------

---------------------------------------------

-------------------------------------------

------------------------------------

--------------------------------

-------------------------------------

-------------------------------------

https://stackoverflow.com/questions/44912/java-delegates

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:

// Java
public interface ISomeBehaviour {
   void SomeFunction();
}

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

// Java
public 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();

// Java
ISomeBehaviour 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.

// Java
public 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 8
SomeMethod(() -> { /* your implementation */ });

-------------------------------

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 void
  can_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.

--------------------------------

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 directory
        fileTotal++;
        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".

-----------------------------------

http://www.javacamp.org/javavscsharp/delegate.html

 
There is no delegate concept in Java
The right-side C# program may be mimiced 
with reflection technology.
====================================
import java.lang.reflect.*;
import java.io.*;
public class Test
{
    public static void main(String[] args) throws Exception
    {
        String[] list= {"to","be","or","not","to","be"};
        Method m1 = Test.class.getMethod("toConsole", 
                           new Class[] {String.class});
        Display(m1, list);
        Method m2 = Test.class.getMethod("toFile", 
                           new Class[] {String.class});
        Display (m2, list);
    }
    public static void toConsole (String str)
    {
        System.out.print(str+" ");
    }
    public static void toFile (String s)
    {
        File f = new File("delegate.txt");
        try{
            PrintWriter fileOut = 
               new PrintWriter(new FileOutputStream(f));
            fileOut.write(s);
            fileOut.flush();
            fileOut.close();
        }catch(IOException ioe) {}
    }
    public static void display(Method m, String[] list)
    {
        for(int k = 0; k < list.length; k++) {
            try {
                Object[] args = {new String(list[k])};
                m.invoke(null, args);
            }catch(Exception e) {}
        }
    }
}
 

 
Delegates are reference types which allow 
indirect calls to methods. There are single and multicast
delegates.
============================================
 using System;
 using System.IO;
 public class DelegateTest
 {
     public delegate void Print (String s);
     public static void Main()
     {
         Print s = new Print (toConsole);
         Print v = new Print (toFile);
         Display (s);
         Display (v);
     }
     public static void toConsole (String str)
     {
         Console.WriteLine(str);
     }
     public static void toFile (String s)
     {
         File f = new File("delegate.txt");
         StreamWriter fileOut = f.CreateText();
         fileOut.WriteLine(s);
         fileOut.Flush();
         fileOut.Close();
     }
     public static void Display(Print pMethod)
     {
         pMethod("This should be displayed in the console");
     }
 }
 A delegate instance encapsulates one or more methods, 
 each of which is referred to as a callable entity. 
 To add or reduce a list of calls
 by using operators += or -=.
 for example
 Print p = s + v;
 s += v;
 

-------------------------------------------

In C# you can define delegates anonymously (even though they are nothing more than syntactic sugar). For example, I can do this:

public string DoSomething(Func<string, string> someDelegate)
{
     // Do something involving someDelegate(string s)
} 

DoSomething(delegate(string s){ return s += "asd"; });
DoSomething(delegate(string s){ return s.Reverse(); });

Is it possible to pass code like this in Java? I'm using the processing framework, which has a quite old version of Java (it doesn't have generics).

Pre Java 8:

The closest Java has to delegates are single method interfaces. You could use an anonymous inner class.

interface StringFunc {
   String func(String s);
}

void doSomething(StringFunc funk) {
   System.out.println(funk.func("whatever"));
}

doSomething(new StringFunc() {
      public String func(String s) {
           return s + "asd";
      }
   });


doSomething(new StringFunc() {
      public String func(String s) {
           return new StringBuffer(s).reverse().toString();
      }
   });

Java 8 and above:

Java 8 adds lambda expressions to the language.

    doSomething((t) -> t + "asd");
    doSomething((t) -> new StringBuilder(t).reverse().toString());

---------------------------------------------------

Your example would look like this in Java, using anomymous inner classes:

interface Func {
    String execute(String s);
}

public String doSomething(Func someDelegate) {
    // Do something involving someDelegate.execute(String s)
}

doSomething(new Func() { public String execute(String s) { return s + "asd"; } });
doSomething(new Func() { public String execute(String s) { return new StringBuilder(s).reverse().toString(); } } });

---------------------------------------------------------

----------------------------------------------------------

----------------------------------------------------------

---------------------------------------------

https://github.com/tim-group/karg/blob/master/src/main/java/com/timgroup/karg/reflection/Delegator.java

https://github.com/tim-group/karg/blob/master/src/test/java/com/timgroup/karg/reflection/DelegatorTest.java

------------------------------------------

Java Proxy class

http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/Proxy.html

-------------------------------------------

State of the Lambda

http://cr.openjdk.java.net/~briangoetz/lambda/lambda-state-final.html

-----------------------------------------------