This is something like Reflection where you can call a method simply by its name, and not a precompiled pointer to it.
Like in JavaScript you can:
var fun = function(){ alert("Hello World!"); }
fun();
Is something like that possible in Java/J2ME? How?
If you want an interpreter for j2me, you could check out Hecl: http://www.hecl.org
You definitely can't do most of the 'fancy' things you can do in normal Java in J2ME. The alternative is a series of if/elseif's that then call the function you want, but you still have to know that ahead of time so that you can write the code that does that.
One way to imitate this functionality is to create a strategy class.
interface Function
{
Object call(Object[] arguments);
}
To do what you suggested, simply do the following (a bit more verbose, as Java typically is):
static class Fun implements Function
{
public Object call(Object[] arguments)
{
System.out.println("Hello, world");
return null;
}
}
Function fun = new Fun();
fun.call(null);
Depending on the situation, you might be able to use better types or generics instead of Object and Object[] (in this case, I used them for maximum flexibility, but they don't give you much in the way of type checking so it's not ideal).
For more information, look at the strategy design pattern.
The common way of getting something like Javascript's closures is using anonymous inner classes. It's a lot more verbose, but it lets you do pretty much the same thing.
Runnable r = new Runnable(){
public void run(){
System.out.println("Hello, world!");
}
};
r.run(); // Prints "Hello, world!"
You can even reference variables in the enclosing method, if they're final:
public static Runnable makeGreeter(final String who) {
return new Runnable() {
public void run() {
System.out.println("Hello, " + who + "!");
}
};
}
// ... elsewhere in your program...
Runnable r = makeGreeter("world");
r.run(); // "Hello, world!"
This is standard stuff which has been in Java since the beginning. Runnable is a very handy interface which, according to the Javadocs, "should be implemented by any class whose instances are intended to be executed by a thread". Runnable can be used for a lot more than threads, of course, and is generally used (in the JVM and elsewhere) as "something that can be executed" - pretty much like a function in Javascript. Of course, if you want to pass arguments, you'd have to make your own interface, but those can be implemented anonymously as well. For example, using #Imagist's Function interface:
interface Function {
Object call(Object[] arguments);
}
// ...
Function helloSayer = new Function(){
public Object call(Object[] args){
System.out.println("Hello, " + args[0] + "!");
}
};
helloSayer.call(new Object[]{ "world" }); // "Hello, world!"
Edit: This has nothing to do with reflection, of course, but there's no reflection in your example either - just an anonymous function.
Are you after the dynamic creation of methods or Reflection?
The first you can't do in Java but you could use an interpreter (BeanShell if you want Java).
There are at least a few ways:
You could create classes at runtime with BCEL, but you have to create the bytecodes yourself. And the JVM's verifier might reject your class if your bytecodes look iffy. Not a super easy solution but doable.
Sun's Java 6 implementation includes Rhino, the JavaScript interpreter, so you can perhaps do what you need if you're willing to use a little JavaScript.
I'm not too sure about this but I believe if you have the JDK installed, you can invoke javac from your Java program. javac's output could be loaded at runtime with a custom ClassLoader class.
Related
What is the best and easiest way to implement callback mechanism in java 8?
Is it to easily replace inner class decleration with lambda experission?
Like replacing
doSomethingAndRunThisCode(new Call() {
#Override
public void callback() {
System.out.println("here I am called back");
}
});
with
doSomethingAndRunThisCode(() -> {
System.out.println("here I am called back");
});
But I think this is not all. Because pre java 8 way is even easier due to code complition of eclipse. Eclipse does nothing on java 8 way of implementing it (yet) .
Yes, you can replace the inner class definition. So long as the interface being expected by the method you are calling has 1 unimplemented method, you can use the lambda syntax.
So what you did above is correct. Also, as someone pointed out, there is the function reference syntax, but that function reference you pass has to have a signature that is coercable to your interface. For instance, take the Consumer interface:
public interface Consumer<T> {
void accept(T t);
}
public class MyClass {
void doSomething(Consumer<String> consumer) { }
}
In this case, you can pass any function reference to the "doSomething" method which has a void return, and accepts a single parameter as a string.
ie.
myClassInstance.doSomething(System.out::println);
I'm not sure about eclipse, as i haven't used the latest versions, but I know Intellij 13 supports the lambda syntax. And even if you're not using java8, it will fold your code into that syntax to make it easier to read (don't worry, it doesn't save it that way, it's just a presentation thing that you can unfold if desired).
While studying Java tutorials, Reflection and Late Binding have confused me. In some tutorials, they have written that they are both the same, and that there isn't any difference between Reflection and Late Binding. But other tutorials say that there is a difference.
I am confused, so can someone please explain what Reflection and Late Binding are in Java, and if posible, please give me some real world examples of both.
Thanks..
Java uses late-binding to support polymorphism; which means the decision of which of the many methods should be used is deferred until runtime.
Take the case of N classes implementing an abstract method of an interface (or an abstract class, fwiw).
public interface IMyInterface {
public void doSomething();
}
public class MyClassA implements IMyInterface {
public void doSomething(){ ... }
}
public class MyClassB implements IMyInterface {
public void doSomething(){ ... }
}
public class Caller {
public void doCall(IMyInterface i){
// which implementation of doSomething is called?
// it depends on the type of i: this is late binding
i.doSomething();
}
}
Reflection is used instead to describe code which is able to inspect other code, ie. to know which methods or attributes are available in a class, to call a method (or load a class) by name, and doing a lot of very interesting things at runtime.
A very nice explaination of reflection is here: What is reflection and why is it useful?
Late binding (also known as dynamic dispatch) does not need reflection -- it still needs to know which member to dynamically bind to at compile-time (i.e. the signature of the member is known at compile-time), even though the binding to overridden members happens at run-time.
When doing reflection, you don't even know which member you're using (not even the name is known at compile-time, let alone the signature) -- everything happens at run-time, so it's a lot slower.
Real world examples:
If you build your project with jdesktop 0.8, but ship with jdesktop 0.9, your code will still use the 0.9 features, because it takes advantage of late binding, i.e. the code that your code calls is the version that is loaded by the class loader, irrespective of the version that it was compiled against. (This is as opposed to linkers, which embed the compile-time version of the called code into the application.)
For reflection, let's say you are trying to target Java 1.5 and 1.6, but want to use tab components in 1.6 if they are available, then you'll check for their presence by using reflection on the JTabbedPane class to find the setTabComponentAt method. In this case you're building against Java 1.5, which doesn't have those features at all, so you can't call them directly or the compile will fail. However if on the end-user's system you find yourself running against 1.6 (late binding comes into play here) you can use reflection to call methods that didn't exist in 1.5.
They are related; many uses of reflection rely on late binding to be useful, but they are fundamentally different aspects of the language and its implementation.
One important issue which is addressed by "Late Binding" is the polymorphism, i.e. that the call of the proper overriden method along your class hierachy is determined during the run-time, not during compilation. Reflection is the feature to gather and manipulate information about your objects during run-time. E.g. you can get all attributes or method names of an object using its 'Class' attribute during the runtime and call those methods or manipulate its attributes.
In following code you can dynamically create a new object by the means of reflection (see how the constructor is retrieved and accessed using a Class, instead of using simply something like object obj = new MyClass( "MyInstance" ) ). In a similar way it is possible to access other constructor forms, methods and attributes. For more information about reflection in java visit: http://java.sun.com/developer/technicalArticles/ALT/Reflection/
... in some method of some class ...
Class c = getClass();
Constructor ctor = c.getConstructor( String.class );
Object obj = ctor.newInstance( "MyInstance" );
I have to disagree with most of the responses here -
Everyone calls what Java does in terms of zeroing in on a method implementation at runtime as late binding, but in my opinion its not correct to use the term late binding for what java does.
Late binding implies absolutely no checks on a method call at compile time and no compilation errors if the method does not exist.
Java however will throw a compile error if the method does not exist somewhere in the type hierarchy of the type qualifying the method call (being somewhat approximate when describing the behavior here). This is not pure traditional late binding.
What Java does in a normal non private non final non static method call would be better termed as dynamic dispatch.
However if we use reflection in Java, then Java does perform pure late binding as the compiler simply cannot verify if the called method exists or not.
Here is an example:
class A
{
public void foo()
{
System.out.println("Foo from A");
}
}
class B extends A
{
public void foo()
{
System.out.println("Foo from B");
}
}
public class C
{
public static void main(String [] args)
{
A a=new A();
B b=new B();
A ref=null;
Class ref1 = null;
ref1 = b.getClass();
ref.foo1();//will not compile because Java in this normal method
//call does some compile time checks for method and method
//signature existence. NOT late binding in its pure form.
try {
ref1.getMethod("foo1").invoke(null); //will throw a
//NoSuchMethodException at runtime, but compiles perfectly even
//though foo1 does not exist. This is pure late binding.
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
This question already has answers here:
What is inlining?
(10 answers)
Closed 9 years ago.
I've been trying to understand what that really means :
inline function
In C++, a member function defined in
the class declaration. (2) A function
call that the compiler replaces with
the actual code for the function. The
keyword inline can be used to hint to
the compiler to perform inline
expansion of the body of a member or
nonmember function.
inline
To replace a function call with a copy
of the function's code during
compilation.
For example it is written something like :
When a method is final, it may be
inlined.
Here : http://www.roseindia.net/javatutorials/final_methods.shtml
Can you give me an example or something or basically help me to understand what "it may be inlined" means.
Thanks.
Inlining is an optimization performed by the Java Just-In-Time compiler.
If you have a method:
public int addPlusOne(int a, int b) {
return a + b + 1;
}
which you call like this:
public void testAddPlusOne() {
int v1 = addPlusOne(2, 5);
int v2 = addPlusOne(7, 13);
// do something with v1, v2
}
the compiler may decide to replace your function call with the body of the function, so the result would effectively look like this:
public void testAddPlusOne() {
int v1 = 2 + 5 + 1;
int v2 = 7 + 13 + 1
// do something with v1, v2
}
The compiler does this to save the overhead of actually making a function call, which would involve pushing each parameter on to the stack.
This can clearly only be done for non-virtual functions. Consider what would happen if the method was overriden in a sub class and the type of the object containing the method isn't known until runtime...how would the compiler know what code to copy: the base class's method body or the sub class's method body? Since all methods are virtual by default in Java, you can explicitly mark those which cannot be overriden as final (or put them into a final class). This will help the compiler figure out that method will never be overriden, and it is safe to inline. (Note that the compiler can sometimes make this determination for non-final methods as well.)
Also, note the word may in the quote. Final methods aren't guaranteed to be inlineable. There are various ways you can guarantee a method isn't capable of being inlined, but no way to force the compiler to inline. It will almost always know better than you anyway when inlining will help vs. hurt the speed of the resulting code.
See wikipedia for a good overview of benefits and problems.
Let's say you have a class that looks like this:
public class Demo {
public void method() {
// call printMessage
printMessage();
}
public void printMessage() {
System.out.println("Hello World");
}
}
The call to printMessage could be "inlined" in the following way:
public class Demo {
public void method() {
// call printMessage
System.out.println("Hello World"); // <-- inlined
}
public void printMessage() {
System.out.println("Hello World");
}
}
(This is actually not done on the level of Java (not even on bytecode level) but during JIT-compilation, but the example above illustrates the concept of inlining.)
Now consider what would happen if the printMessage method was overloaded by another class, like this:
class SubDemo extends Demo {
public void printMessage() {
System.out.println("Something else");
}
}
Now if the compiler inlined the call to Demo.printMessage it would be stuck with System.out.println("Hello World"); which would be wrong in case the object was actually an instance of SubDemo.
However, if the method was declared final this would not under any circumstances be the case. If the method is "final" it means that it can never be overridden with a new definition, thus, it is safe to inline it!
Calling a function is not free. The machine must maintain a stack frame so that it can return to the calling section of code when the called function is complete. Maintaining the stack (including passing function parameters on this stack) takes time.
When a function is in-lined, the compiler replaces the call to the function with the function's code so that one can avoid the performance penalty of a function call at run-time. This is one of the classic trade-offs in programming: the run-time code gets a little bigger (takes up more memory), but it runs a little faster.
Is there any other way in java to implement call backs apart from inner classes? What is the difference between callbacks and closures?
Closure is how you build it, callback is how you use it.
A callback can be implemented as a closure (in languages that have them) or an implementation of an interface (in Java, as an anonymous inner class or a regular class).
Callback means that you pass a piece of code to a function, so that the function can call that piece of code later. It is a special kind of parameter.
The piece of code can be a function pointer or a closure or an object with well-known methods, depending on what the language offers.
Both closures and anonymous inner classes (and others) can be used as callbacks. A callback is just some code which is passed as an argument to other code.
A big difference of closures, compared to Java's anonymous inner classes, is that (in imperative languages) a closure can modify the variables of the surrounding scope. Wikipedia gives the following example:
var f, g;
function foo() {
var x = 0;
f = function() { return ++x; };
g = function() { return --x; };
x = 1;
alert('inside foo, call to f(): ' + f()); // "2"
}
foo();
alert('call to g(): ' + g()); // "1"
alert('call to f(): ' + f()); // "2"
A callback is just any executable code that is passed as a parameter to other code. In frequent usage, that executable code is a closure, but it's not necessarily.
The word closure is somewhat abused and many people just use it as a synonym for "anonymous function", but at least according to Wikipedia, that's a misuse of the term. The Wikipedia article explains this better than I can do quickly.
If you need closures in java you could try lambdaj. Here you can see how it allows to define closures through a very straightforward DSL.
I don't think so.
If there is, then it is probably inferior in some way, otherwise anonymous inner classes wouldn't be widely used.
There is no difference.
Closures can be defined as a block of code holding parent context that can be executed with ease.
In fact, the only difference I know between those is the ease of writing. A typical groovy/ruby closure is indeed smaller to write than a Java anonymous class.
However, considering Java framworks like guava and there liberal use of anonymous classes/interfaces, particularly for typical closures use cases like filter (comparing with groovy's implementation), I can say there is absolutely no design difference.
Sadly the only reasonable way is inner/anonymous classes.
You can also do it with reflection, but that usually is slower and harder in maintenance (no syntax highlighting, hard to find references in IDE etc.). An example:
myButton.addActionListener(EventHandler.create(ActionListener.class, handlerObject, "onClick"));
For now anonymous classes are the best way of handling callbacks in Java. However this is likely to change come Java 7 which will implement closures. http://en.wikipedia.org/wiki/Closure_(computer_science)
Here it is two implementations that uses closures and callbacks.
http://www.caglargonul.com/2013/04/05/playing-with-closures-in-java-7/
http://www.caglargonul.com/2013/04/05/java7-callback-implementation/
And here is a better example (can be found here http://www.caglargonul.com/2013/04/10/is-it-really-a-closure-yes-it-is/ ) for understanding what closure is. The key is that
a closure comes with a referencing environment not just a function code.
The best way to implement a closure in Java 7 and below is using an interface. In this example a callback is implemented as closure.
You first declare your interface which will hold your closure.
public interface CallBack {
void m(int e);
}
And lets add a class responsible for holding an array of closures, two public methods for adding and removing closures and a public function which will call the functions inside the closures when an event occurs.
public class CCallBack {
List<CallBack> cbs = new ArrayList<>();
public void registerCallBack(CallBack f){
cbs.add(f);
}
public void removeCallBack(CallBack f){
if(cbs.contains(f)){
cbs.remove(f);
}
}
public void onAction(int i){
for (CallBack callBack : cbs) {
callBack.m(i);
}
}
}
And here is the magical part. See the referencing environment in action.
public class CallBackTester {
CCallBack cb = new CCallBack();
#Test
public void test_callback(){
CallBack cb1 = new CallBack() {
int x = 1;
#Override
public void m(int e) {
if(e==1){
System.out.println("You register this callback " + x + " time/times");
x++;
}
}
};
cb.registerCallBack(cb1);
cb.registerCallBack(cb1);
cb.registerCallBack(cb1);
cb.removeCallBack(cb1);
cb.onAction(1);
}
}
Above when we declare cb1 we are adding a referencing environment which consists of the variable x. When we call the function inside this closure we are incrementing this variable by one. If it was a normal function, x would have been declared as 1 when we call the function. BUT IT IS NOT A NORMAL FUNCTION. IT IS A CLOSURE. So x is not declared every time we call the function in the closure. As you can see from the output every time we call it, x is incrementing.
You register this callback 1 time/times
You register this callback 2 time/times
Does the Java language have delegate features, similar to how C# has support for delegates?
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:
// 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 */ });
Short story: no.
Introduction
The newest version of the Microsoft Visual J++ development environment
supports a language construct called delegates or bound method
references. This construct, and the new keywords delegate and
multicast introduced to support it, are not a part of the JavaTM
programming language, which is specified by the Java Language
Specification and amended by the Inner Classes Specification included
in the documentation for the JDKTM 1.1 software.
It is unlikely that the Java programming language will ever include
this construct. Sun already carefully considered adopting it in 1996,
to the extent of building and discarding working prototypes. Our
conclusion was that bound method references are unnecessary and
detrimental to the language. This decision was made in consultation
with Borland International, who had previous experience with bound
method references in Delphi Object Pascal.
We believe bound method references are unnecessary because another
design alternative, inner classes, provides equal or superior
functionality. In particular, inner classes fully support the
requirements of user-interface event handling, and have been used to
implement a user-interface API at least as comprehensive as the
Windows Foundation Classes.
We believe bound method references are harmful because they detract
from the simplicity of the Java programming language and the
pervasively object-oriented character of the APIs. Bound method
references also introduce irregularity into the language syntax and
scoping rules. Finally, they dilute the investment in VM technologies
because VMs are required to handle additional and disparate types of
references and method linkage efficiently.
Have you read this :
Delegates are a useful construct in event-based systems. Essentially
Delegates are objects that encode a method dispatch on a specified
object. This document shows how java inner classes provide a more
generic solution to such problems.
What is a Delegate? Really it is very similar to a pointer to member
function as used in C++. But a delegate contains the target object
alongwith the method to be invoked. Ideally it would be nice to be
able 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 this
functionality via anonymous inner classes and thus does not need the additional
Delegate 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 the
Delegates syntax is very attractive.
General Handler
However, if event-based programming is used in a more
pervasive manner, say, for example, as a part of a general
asynchronous programming environment, there is more at stake.
In such a general situation, it is not sufficient to include only the
target method and target object instance. In general there may be
other parameters required, that are determined within the context when
the event handler is registered.
In this more general situation, the java approach can provide a very
elegant solution, particularly when combined with use of final
variables:
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 anonymous
class method definitions. Be sure to study this code carefully to
understand the ramifications. This is potentially a very powerful
technique. For example, it can be used to good effect when registering
handlers in MiniDOM and in more general situations.
By contrast, the Delegate construct does not provide a solution for
this more general requirement, and as such should be rejected as an
idiom 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 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.
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 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".
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.
With safety-mirror on the classpath you get something similar to C#'s delegates and events.
Examples from the project's README:
Delegates in Java!
Delegate.With1Param<String, String> greetingsDelegate = new Delegate.With1Param<>();
greetingsDelegate.add(str -> "Hello " + str);
greetingsDelegate.add(str -> "Goodbye " + str);
DelegateInvocationResult<String> invocationResult =
greetingsDelegate.invokeAndAggregateExceptions("Sir");
invocationResult.getFunctionInvocationResults().forEach(funInvRes ->
System.out.println(funInvRes.getResult()));
//prints: "Hello sir" and "Goodbye Sir"
Events
//Create a private Delegate. Make sure it is private so only *you* can invoke it.
private static Delegate.With0Params<String> trimDelegate = new Delegate.With0Params<>();
//Create a public Event using the delegate you just created.
public static Event.With0Params<String> trimEvent= new Event.With0Params<>(trimDelegate)
See also this SO answer.
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 well
class 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.