Funcito: wrap Java methods for FP libraries

On and off, I've been collaborating with my friend, Kevin Welker, on an open-source project: Funcito. This is really his baby, but it has been great fun to be involved (more to come in another post).

Executive Summary

From the FAQ, Funcito is a Java library that simplifies access to functional programming APIs by wrapping Java methods as the function-type objects defined in those libraries. It reduces boilerplate now, without waiting for changes in Java 8.

The syntax (and internals) is influenced by Mockito, the popular mocking framework. However, Funcito is not aimed at testing.

It supports specific interfaces in Google Guava, Functional Java, and Jedi-core. See the project page for details.

Example in straight Google Guava

Here is example code for using Google Guava, using a List of Song objects.

The setup is simply populating the list:

public void init() {
    // List<Song> songs is a member
    songs.add( new Song("Help!", "The Beatles", new BigDecimal(1.29) ) );
    songs.add( new Song("You Had Time", "Ani DiFranco", new BigDecimal(0.99) ) );
    songs.add( new Song("Shoot to Thrill", "AC/DC", new BigDecimal(0.89) ) );
    songs.add( new Song("Back in Black", "AC/DC", new BigDecimal(0.89) ) );
    songs.add( new Song("Indie Song", "Obscure Band", BigDecimal.ZERO ) );
    songs.add( new Song("Demo Track", "College Jam", BigDecimal.ZERO ) );
}

Here is an example test, using a predicate method on Song, isFree(), to filter for free songs:

public Collection<Song> filterFreeSongs() {
    // boilerplate alert!  
    Predicate<Song> isFreePredicate = new Predicate<Song>() {
        public boolean apply(Song s) { return s.isFree(); }
    };

    Collection<Song> freeSongs = Collections2.filter(songs, isFreePredicate);

    // size == 2 in example
    return freeSongs;
}

Note the typical pattern to build a Predicate, even though the object is simply calling a boolean method. Funcito addresses precisely this issue.

Example with Funcito

Using the same setup, here is the same test using Funcito. Note the proxy object, CALLS_TO_SONG:

// member of class
// using static import of Funcito's callsTo    
private Song CALLS_TO_SONG = callsTo(Song.class);

public Collection<Song> filterFreeSongs() {
    // using static import of Funcito's predicateFor    
    Predicate<Song> isFreePredicate = predicateFor(CALLS_TO_SONG.isFree());

    Collection<Song> freeSongs = Collections2.filter(songs, isFreePredicate);

    // size == 2
    return freeSongs;
}

Less boilerplate, with improved readability and a fluid syntax!

The Upshot

If you are using straight-up FP libraries in Java, and want to reduce some of the boilerplate, check out Funcito. It's lightweight with minimal dependencies (either CGLib or Javassist), and can help you wrap up simple Java methods.

Top Ten Reasons Java Developers Fear The Oracle Buyout

It is huge news indeed, and so without further ado, here are the Top Ten Reasons why Java developers fear the Oracle buyout:

#10 Any Java class with the name Table in it will have a 30 character limit

#9 Your favorite open-source IDE will become a Toad plugin

#8 Applications will become known as Enterprise Stored Procedures

#7 Ignoring silly hexadecimal, the CEO will insist the venerable CAFEBABE header be changed to IAMLARRY

#6 Prospective JavaOne speakers will need to win a yacht race as part of the acceptance process. JavaOne itself will be held on a desert island.

#5 The beloved Java Posse will suddenly resurface as the PL/SQL Posse

#4 The classloader will become a fork of MySQL and require a series of certification tests before modification

#3 The next version of Java will be known as JDK 7g

#2 A new Swing API will replace EventListener with TNSListener, requiring annoying server configuration.

and the top reason Java developers fear the Oracle buyout:

#1 DBAs will park in reserved slots, acquire window offices, and gleefully demand that everything goes into Fourth Normal Form.

If you like this kind of humor, come on over to a brand-new Twitter feed...

Introducing @patentlyfalse (read more here).

Even if you aren't on Twitter, here is an RSS feed.

3 Lessons from WAX

There is a new JNB article over on my employer's site. The topic this month is a new API for writing large XML documents: WAX. Here are 3 lessons I've learned from the article.

1. Research, Build, Contribute

Mark ran into a real world problem (an OutOfMemoryError when writing a large XML doc), then surveyed the landscape for a solution. Not satisified with the answers, he wrote his own solution and shared his findings with the world. Classic stuff.

2. Use Interfaces to Communicate Intent

The article mentions, as an aside, a clever idea by Brian Gilstrap: the use of interfaces to restrict the usage of the WAX API. For example, one may not call the attr method after using the text method. Brian's idea creates support for a DSL, of sorts, in a static language: it hits a sweetspot that provides compile time support and yet does not use a full-blown parser or dynamic-language DSL.

3. Have Fun

Well, check out the introduction video and see for yourself. I *heart* absurdity !

JML: JSR Modeling Language

This month, I've been writing an article on JSR 181: metadata for Web Services (WS).

A big part of the learning experience was untangling the knot of JSRs that make up the WS space: it's complex.

Actually it's a testament to the vibrancy of the Java community, and the success of the JSR/JCP process. But I think we have reached a point where the number of JSRs are unwieldy.

Because of the volume of JSRs, and also because of the relationships among them, I think we need to start looking at JSRs graphically. In fact, I think we should borrow from our friends in the UML and design pattern camp.

Consider JML: the JSR Modeling Language. Check out the examples in the diagram.


That JAXB uses annotations is an easy example, but it took me days to realize that JSR 181 is essentially the facade pattern for JSR 224! It also took some time to realize that these relationships need not apply to objects: they can apply to JSRs. (Note that many original design patterns came from architecture, not OO.)

The diagram is crude, but I tell you: whoever illustrates a schematic of JSRs on a nice, large poster will make money.

Yet another profitable idea from Code To Joy... if only there were more hours in the day. Alas, I don't have time so I donate the idea to you all.

Art and XML: Reactions Against Complexity

Recently, I've thought about a common theme between art and computer science: the "reaction against complexity".

This phrase seems to come up a lot in art, whether it is music, architecture, or visual art. Almost all of the schools (e.g. the Impressionists) seem to come about in reaction to something. Often, it is complexity.

The Bubble

I wonder if anything sets out to be complicated. It often seems like there is an idea that is embraced, then added to, reused, refactored, and eventually pushed into an ever-expanding range of uses. Then, there is a lightning bolt that jars everyone into the realization that, "hey, we are in an era of complexity right now -- how did that happen?".

Here's some examples from art... (These may be grossly over-simplified!)

Grunge

An easy, contemporary example is hard rock/metal in the late 1980s (in North America and Europe). Throughout the decade, the style had grown from its bluesy roots in Led Zeppelin to having shrill, operatic vocals, and guitar solos with amazing technical virtuosity. Bombastic looks and videos ruled the day.

Then along came a band out of Seattle, and nothing was the same. Seemingly overnight.

Cool Jazz

In the 1940's, a primary form of American jazz was bebop. Bebop was known for its fast tempos and sophisticated ideas for melody, harmony, and rhythm. Miles Davis, in his first stint as band leader, took things in a new direction with a landmark recording called "Birth of the Cool". To quote this website, "The cool jazz style has been described as a reaction against... [the excess] of bebop and is generally more relaxed". There's that phrase again.

Modern Architecture

Modern architecture is a style that began in the early 20th century. It's characterized by simple geometric lines and a distinct lack of ornamentation. Ultimately, it led the way to the skyscraper. To quote one of the founders, Ludwig Mies van der Rohe: "Less is more". (Sound familiar in the geek world?)

To paraphrase Wikipedia, some historians feel that the Modern school is a "reaction against" the excesses of the movement known as Art Nouveau (an example is here).

Convention over configuration

This is not news but we geeks seem to be emerging from an orgy of XML (aka The Bubble), where it has been used for everything. Most of this use is predicated by configuration: Struts 1.x, EJB 2, and the list goes on.

Of course, the lightning bolt has been Ruby on Rails. Most readers will know that the bumper sticker for the RoR camp is "convention over configuration": just do the natural thing with a minimal, simple set of files, and the framework will take care of the rest. Why over-specify everything all the time?

Similarly, annotations have simplified EJB 3 and JAX-WS. XML is invaluable, no doubt, but perhaps the days of excess are over? I have heard several speakers talk about the "old days of XML hell" with "legacy" frameworks (which are only a few years old).

Perhaps this is Struts 1.x?

Perhaps the historians will talk about a new age of frameworks "as a reaction against complexity"....

The Upshot

Whether it's in your own project or in the Java scene, keep an eye out for complexity and note the reactions to it. It's fun to guess what the "next bubble" will be. Based on patterns in art, my guess is that annotations themselves will be the Next Bubble. They fix a problem, are being embraced, then added to, reused -- wait, haven't we heard this before?

Java: What's All the Excitement About? (1997)

In this post, Weiqi Gao quietly mentions that the St Louis Java User's Group had a talk by Mark Volkmann, 10 years ago this month, on Java: What's All the Excitement About?

It's a quick, fun read to go back in time with the slides. I don't think we need another "10 year retrospective", but here are some random thoughts.

• There's dozens of issues that have been wildly successful. Suffice it to say that, despite stumbling out of the gate, Java is certainly a Hall of Fame language and platform.
• The performance issue is continually pushed to the next layer. Ages ago, C probably wasn't fast enough. Then C++. Then Java. Now it's Groovy and JRuby. Plus ça change, plus c’est la même chose!
  
• Garbage collection algorithms have been the "NASA Space Program" of Java: it is amazing what bright people can do with focus and purpose.
  
• Webapp technology has changed drastically, and yet the Java space still doesn't agree on a framework.
• Does anyone explicitly use the Security Manager/policies etc? Perhaps in the EJB space?
  
• It's been 10 years of installing Java programs. There are no words better than the drawings on this timely blog which promises sweet relief in Java6.
  

Easter's Laws of Concurrency

I've been reading Brian Goetz' Java Concurrency in Practice. It has some mind-expanding thoughts on how subtle it can be to have threading problems in Java (or any language).

The book, and Amdahl's Law, has inspired me to codify a warning to junior developers (apprentices, in the parlance of Code to Joy), and as a reminder to the senior devs (composers).

Preface

A program is said to be thread-effective if it is:

• (a) thread-safe
• (b) efficient with respect to concurrency (e.g. throughput, UI responsiveness, etc)

Define a program's probability of thread-effectiveness (PTE) to be a metric ranging from 0 to 1, where 1 is complete certainty of thread-effectiveness.

Easter's 1st Law of Concurrency

If you don't know if your program is thread-effective, then its PTE is approximately 0.

Easter's 2nd Law of Concurrency

If you think that your program is thread-effective, then its PTE follows the specified equation:


where:

• C is a random constant between 0.01 and 0.025
• E is experience

Experience is difficult to define in practice, but an approximation is:






where:

• P is the number of programs successfully debugged with respect to thread-effectiveness
• B is the number of books read (in their entirety) on thread-effectiveness

Easter's 3rd Law of Concurrency

If a progam's thread-effectiveness is not optimal, problems will eventually manifest themselves. This manifestation will follow neither Murphy's Law nor the related Law of Demos.

Instead, the problems will manifest themselves, in production, long after you have moved onto other issues and have forgotten the intricacies of the design. This will leave you to rely on the quality of design and documentation as the primary means of fixing the problem.

One Word for Your Career: Lemmings

To be a virtuoso code composer in Java (or any language), one needs to understand concurrency and the memory model of the platform.

Many of us, myself included, should study and learn as much as we can about these subjects: they truly separate the masters from the apprentices.

The best resource going these days for Java is the book Java Concurrency in Practice. Get it. Just get it. After all, at your next interview, some of your competitors will have read it.

Here's a blog on a study group for the book.

re: title. What's with the lemmings you ask? Many, many moons ago in grad school, I played a wonderful computer game called Lemmings. The gist was that there were many lemmings who would flow from one place to another. They weren't very bright. The game-play was for you to control gates, ramps, and other control structures to guide the little buggers to safety, and to prevent them from causing chaos.

As the levels ratcheted up, the game became frenetic, both in terms of speed and the number of lemmings. I would play with a girlfriend -- one would observe and shout out shorthand commands; the other would operate the devices.

I now realize that we were pair-programming in a multi-threaded environment. If you played the game, you know that the analogy is profound.

ps. From the "brushing teeth after posting dept": this is crazy but I wonder if something like Lemmings could be used to visualize tests against multi-theaded programs. Sort of like a generalized, 2D version of JUnit's green/red bar. As you run the program, the display shows threads (lemmings) exploring the program/data space. It wouldn't be used to prove correctness but rather to show, visually, what is going on for a given execution. It might be illuminating.

pps. An idea that is much smaller in scope. If UML is used to represent the relationships and contracts between objects graphically, is there any such representation for concurrency?

Life After Ant

Here's an interesting post on new-age build tools like Rake and Gant.

A moderately new thought (for me) on build tools:

Things that we use _all the time_ tend to resist change. For example, in natural language, the verbs “to be” and “to have” are notoriously weird because they aren’t made “regular”, as is the tendency with less-used verbs. We don't think about "to have" or "to be": we just use them. All the time.

Similarly, build tools have amazing resilience. The industry suffered with ‘make’ for decades. The fact that Ant saved us from ‘make’ is enough for it to go into the Hall of Fame.

I'm in no hurry to see Ant go away. I am intrigued though by Gant.

Guard Clauses Considered Harmful

A colleague and I have had a long running debate on Guard Clauses, which is an example of "Alligators versus Crocodiles". A previous post tries to present the "for" case.

Now, it's hammer time.

IMO, the canonical form for a Java method is like so:


public MyObject doSomething(Object a, Object b) {
    MyObject result = null;

    // stuff goes here

    return result;
}


It's old-school: a single point of return. Any checks should concentrate on the positive and relegate error messages, exceptions, etc to the else statements at the bottom of the method.

For example:


if( a != null ) {
    if( b != null ) {
        doSomething();
    } else {
        // throw exception
    }
} else {
    // log error
}


Here are the advantages:

• The logic of the method is easy to understand: set the default case first, then change it if necessary. It quickly becomes a pattern that makes reading and debugging code easier.

• It is easy to enforce. There is no slippery slope as with guard clauses. Guard clauses easily degenerate into "open season" for returning from methods all over the place. This is much harder to maintain, and is more prone to bugs, than the (admitted) indentation issue. IDEs can help match braces etc with respect to indentation: may heaven help you if you need to understand a method with several return methods. Note that the example of guard clauses (here) is pristine. It's not always this way.

• Stating the above in a different way, it's easy to scan and find the "heart" of the logic. The corner cases of exceptions and error logging is at the bottom of the method. Guard clauses puts that stuff right up front, which strikes me as being inverted.

• Using a convention is extremely powerful: note that methods that use this format are amenable to being processed by simple scripts etc. e.g. If one wanted to insert "pre"/"post" logic logging (though admittedly this is surpassed by using AOP).

Counters to the "for" case:

• In the purest form, guard clauses are brief statements at the top of the method and, yes, they can be thought of as a pseudo-contract. But when scanning through the method, there is something jarring about seeing a return statement. It invariably opens another thread in my head for that case, and as the returns stack up, so too do these threads. It is distracting.
• An oft-cited argument for guard clauses is that methods in Java are shorter. Hmmm.... maybe. Example methods are shorter, and the pristine methods you and I write are shorter, but does the average Java Joe/Jane really write shorter methods than, say, C++? IMO, the above convention does not harm short methods but definitely assists the reader with the dreaded longer methods. The proper use of guard clauses is just too subtle for Java Joe/Jane.

And there you have it.... As always, I (and my colleague, who is no doubt reading closely) am interested in your feedback.

Do you see guard clauses as an alligator or a crocodile?

ps. I fully concede that this convention doesn't have a sexy term like guard clause and does not get press in popular books. Perhaps fans of this idea can give it a snazzy name (Return on Rails?)

The Case for Guard Clauses

As mentioned in a previous post, an XP pair partner of mine and I would get into debates about Guard Clauses. This is a classic Alligators versus Crocodiles issue.

The idea is, in essence, to return from a method quickly for illegal arguments before hitting the main logic of a method.

Guard clause:

if( a == null ) { return; }
if( b == null ) { return; }
doSomething(a, b);

versus not:

if( a != null && b != null ) {
doSomething(a, b);
} else {
// log error
}

I should probably ask him to "guest host" on this entry, but here's my best, honest attempt to summarize the arguments for guard clauses:

• It's time to bid the 1980s a fond farewell. Methods do not have to adhere to the rule of "having a single point of return", especially in Java, because methods are much shorter now.


• Checking for null etc ultimately leads to serious indentation which is hard to read.


• When done correctly, the guard clauses read like a contract for the method. It's like Checked Exceptions Lite: all the intent without the "propogation" aftertaste.


• It's a refactoring pattern with a cool name!

So there's the Alligator Assessment... next up: the Crocodile Case.