Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Yet Another Reason Why Java Needs Closures

DZone's Guide to

Yet Another Reason Why Java Needs Closures

· Java Zone
Free Resource

Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code! Brought to you in partnership with ZeroTurnaround.

Ever try to unit test code with static method calls? That's right. You know how this feels.

 

class  Untestable{
public void doSomething(){
...
if ( Util.openSocketAndThenGoToFileSystem() )
...
}
}
Unit testing doSomething is often impossible because unit tests simply don't do things like talk to networks or file systems. It's even more "fun" when someone puts code like this in a constructor - that way you can't even instantiate an instance of Untestable outside the production environment.

This is particularly painful in Java (as it stands today) for two reasons. First, there are no open classes. Sure, there is conditional compilation or cglib but at the end of the day, it's never going to be as easy as it is in JavaScript, Python, etc.

Second, it calls a static method. If you haven't read Steve Yegge's post on this matter, verbs are second class citizens in Java. Because each verb must be escorted by a noun at all times, methods cannot be stubbed out or mocked. This limitation has profound side effects on the maintainability (and profitability) of every large Java code base.

Enter Closures ...


We can refactor the Untestable class to a Testable class.
class Testable{

private final { => boolean } collaborator;

Testable({ => boolean } collaborator){
this.collaborator = collaborator;
}

public void doSomething(){
...
if ( collaborator.invoke() )
...
}
}
By declaring a closure instance variable we can use Dependency Injection to exercise the functionality of Testable without doing something expensive. This is a lot easier than retrofitting an interface or inner class. Our test methods now look like this:

public void testDoSomething(){
Testable testable = new Testable({ => true });
testable.doSomething();
assertTrue(true, testable.someSideEffect());
}



Neal Gafter tells me the chances of closures making it into the next version of Java is getting smaller and smaller. I'm keeping my fingers crossed, time will tell. Keep up the good work Neal.

From http://notdennisbyrne.blogspot.com/

The Java Zone is brought to you in partnership with ZeroTurnaround. Check out this 8-step guide to see how you can increase your productivity by skipping slow application redeploys and by implementing application profiling, as you code!

Topics:

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}