Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Closures with CollectionUtils

Here's a pretty nifty trick for using closure's with Jakarta Commons CollectionUtils:

List list = new ArrayList();
CollectionUtils.forAllDo(list, new Closure() {
    public void execute(Object obj) {
    // execute something for each item obj

I wonder if there's any performance hit from doing things this way vs. a good ol' Iterator? Hat tip to Anand Subramanian.

Posted in Java at Apr 13 2005, 08:49:07 AM MDT 18 Comments

I haven't noticed any performance hit with commons-lang's Closures, Predicates and other Collection/ListUtils filters and all. If you look at the source code, you will see it is very lean inside (uses an Iterator).

Posted by Anonymous Coward on April 13, 2005 at 09:26 AM MDT #

And I would be stunned if it wasn't just hiding an iteration anyway. Anyway, this still isn't a true colsure, surely? You don't have the context of the original call - it's just a simple object-as-a-fucntion-pointer type thing, and not something you need commons-collections for

Posted by sam newman on April 13, 2005 at 09:37 AM MDT #

It's definitely not faster and it instantiates a new object every time you call forAllDo(), which polutes the heap. A true closure would be more efficient.

Posted by Nikolay Kolev on April 13, 2005 at 12:12 PM MDT #

There is an article at onJava which describes in some detail Functors framework available as part of Commons Collections.

Posted by Dmitri Maximovich on April 13, 2005 at 12:13 PM MDT #

The possible performance hit is that every time you do a new anonymous class based closure in Java this is in fact an extra class your VM has to manage. These start adding up pretty quickly when you use this programming style. It's pretty sad that Java has nothing similar to C#'s delegates, and no real closure support, when both could have been built in. Expect a blog post (rant) about this from me, it's been on my todo list for 2-3 months now.

Posted by Colin Sampaleanu on April 13, 2005 at 12:26 PM MDT #

Hey Matt - Spring has closure support, too: See org.springframework.core.closure. Juergen is considering this for the 1.2 timeframe, but we're a bit overdue there so it may get pushed back to 1.3.

Posted by Keith Donald on April 13, 2005 at 12:32 PM MDT #

I just checked with Juergen. Closures will in fact make Spring 1.2 final. Coolness.

Posted by Keith Donald on April 13, 2005 at 12:42 PM MDT #

One object per iteration is nothing performance wise. The coding overhead on the other hand:

CollectionUtils.forAllDo(list, new Closure() {
    public void execute(Object obj) {
    // execute something for each item obj


for (Object obj : list) {
    // execute something for each item obj

What's the point of the closure?

Posted by Bob Lee on April 13, 2005 at 01:05 PM MDT #


<em>What's the point of the closure?</em>'s a <strong>CLOSURE</strong>. That <em>has</em> to be better. :-)

Posted by Dennis Doubleday on April 13, 2005 at 02:06 PM MDT #

Bob, This is a pretty cool thing you can do with simulated closures in Java:
Collection foos = ...;

Collection fooBars = new SimpleConstraint<Foo>() {
    public boolean test(Foo foo) {
        return foo.isBar();
I like to call that "simulated internal iteration" -- or something, well, I just made that term up now... The alternative would be this:
Collection foos = ...;

Collection fooBars = new ArrayList<Foo>();
for (Foo foo : foos) {
  if (foo.isBar()) {
The latter is obviously more sensitive to bugs, and the block of code (the if conditional logic) is not reusable in any way. Now for this trivial example it's not that big of deal, but had the block done something more useful then the benefits of simulated Closures in java are more apparent. How's little Bob? :-)

Posted by Keith Donald on April 13, 2005 at 02:29 PM MDT #

I still like my approach better :)

Posted by Alex Winston on April 13, 2005 at 02:34 PM MDT #

How's little Bob?
It's a little Bobbie now. ;)

Posted by Bob Lee on April 13, 2005 at 04:39 PM MDT #

Do we really need closures to perform some action while iterating the elements of a List? Can't we use the Visitor design pattern instead? I'm very much an old fashioned person, and I think that the Visitor approach could work just fine and probably is more extensible and more reusable. Here's an example of what I did when filtering the elements of a List. I've implemented the Visitor pattern to summarize the List's elements as well, and it gets reused a lot throughout my project. Is closures better than Visitor pattern for the iterating purpose? Or did I miss anything here? :D

Posted by Eric Pramono on April 13, 2005 at 10:58 PM MDT #

Matt, what do you use to format your Java source snippets in your blog entries?

Posted by rory on April 14, 2005 at 02:49 AM MDT #

Bob - little girls rock!! Having a Daddy's Little Girl is a lot of fun. <em>Congrats!</em>

Rory - I use a JSPWiki Plugin for Roller.

Posted by Matt Raible on April 14, 2005 at 08:24 AM MDT #

Eric, I checked out your example. While I like it, it's not GoF Visitor. It's closure to what we've been demonstrating - a predicate function object (pun intended;-)). That's more like a strategy than a visitor - the predicate is a conditional algorithm. With a visitor you'd see something like this: The visitor:
public interface ElementProcessorVisitor {
  public void process(Foo fooElement);
  public void process(Boo barElement);
The visitable:
public interface VistableElementCollection {
  public void iterate(ElementProcessorVisitor visitor);
ElementProcessorVisitor visitor = ...
VisatableElementCollection collection = ...
Some similiarity, but the patterns are different. Visitor is all about polymorphic dispatch, to vary behaivioral logic based on an object's type.

Posted by Keith Donald on April 14, 2005 at 12:41 PM MDT #

Thanks Keith for clearing that up to me.. ;-)

Posted by Eric Pramono on April 14, 2005 at 10:43 PM MDT #

I agree with Bob. The only case when this Jakarta or Spring predicates/closures would make sense is if you are using the same kind of operation on many places. If such operation is stateles then you can share the same static instance everywhere, but if it is not static there will be a hard hit to memory heap as Colin pointed out.

Posted by eu on April 27, 2005 at 09:20 PM MDT #

Post a Comment:
  • HTML Syntax: Allowed