Archive

Posts Tagged ‘Java’

Google collections and enhanced JavaBeans

November 4th, 2009 David Gageot 7 comments

I’m a big fan of Google Collections. Functions and Predicates became my best friends to make Java’s syntax a bit functional-like. I like writing things like:

List<Contact> contacts = ...
List<String> toStrings = Lists.transform(contacts, Functions.toStringFunction());

and with the help of static imports:

List<String> toStrings = transform(contacts, toStringFunction());

If you use out-of-the-box Functions and Predicates, it’s a lot of fun. Now, let’s say, you want something more useful like:

List<String> names = transform(contacts, Contact.T0_NAME);

you need to accommodate with Java’s way of writing functions. That is write an inner class:

public class Contact {
...
public static Function<Contact, String> TO_NAME = new Function<Contact, String> {
    public String apply(Contact contact) {
        return contact.getName();
    }
}

It’s ok for one bean property, but writing functions for all of them is a lot of work.

What if we could write a JavaBean that would generate all these functions for us. Something like that:

public class Contact extends AbstractBean<Contact> {
public static final StringProperty<Contact> NAME = stringValue();
public static final IntegerProperty<Contact> AGE = integerValue();
public static final StringProperty<Contact> EMAIL = stringValue();

public Contact(String name, int age, String email) {
    super(NAME, name, AGE, age, EMAIL, email);
}

public String getName() {
    return get(NAME);
}

public Integer getAge() {
    return get(AGE);
}

public String getEmail() {
    return get(EMAIL);
}
}

Now, every property of my bean is also a Function converting a bean instance to it’s property value. To be clear:

Contact.NAME is a Function<Contact, String>
Contact.AGE is a Function<Contact, Integer>
Contact.EMAIL is a Function<Contact, String>

so that I can write:

List<Contact> contacts = ...
List<String> names = transform(contacts, Contact.NAME);
List<Integer> ages = transform(contacts, Contact.AGE);

Nice isn’t it?

Now, it can be even cooler. I can write something like that:

Iterable<Contact> david = filter(contacts, NAME.isEqualTo("david"));
... adults = filter(contacts, AGE.isGreaterThan(18));
... babies = filter(contacts, NAME.isEqualTo("baby").and(AGE.isLessThan(1)));

My bean properties are also Predicate factories!

With a custom utility class, I can even use a clearer syntax that Google Collection’s:

... ages = with(contacts).keep(NAME.isEqualTo("david")).to(AGE).list();

There are even more features. All AbstractBeans come with free equals(), hashCode() and compare().

The last neat feature is the ability to write a builder for any bean easily, with only one additional method:

public class Contact extends AbstractBean<Contact> {
...
static <V> BeanBuilder<Contact> with(BeanProperty<Contact, V> property, V value) {
    return new BeanBuilder<Contact>() {
        public Contact createBean(PropertyValues<Contact> values) {
            return new Contact(values.get(Contact.NAME), values.get(Contact.AGE));
        }
    }.with(property, value);
}

Now, I can write something like this:

Contact contact = with(NAME, "david").with(AGE, 34).with(EMAIL, "d@g.net").build();

Note, that all of the features are statically typed and don’t use reflection.

What do you think?

Mockito’s partial mocks. Testing real objects just got easier

June 21st, 2009 David Gageot 3 comments

In this article (in french), I wrote 6 months ago, I was searching for a mockito-like syntax to stub only one method of an object instance under test. Mockito brought it in it’s latest version. Read more…

I don’t like inheritance in Java and now I know how to explain why

June 19th, 2009 David Gageot 16 comments

I tend to dislike very very much class inheritance in Java. However, until today, it was not easy to explain why.

I’ve always said that beginners do a lot of duplication when they code, medium programmers solve this problem using class inheritance, good programmers find every possible way to abstract even more and get rid of class inheritance, sometimes even for the price of a small duplication (due mainly to java limitations).

If you search keyword extends in your code base, how many times doest it appear compared to keyword class? Read more…

Tags: ,

Java libraries and frameworks supported by Google App Engine

April 12th, 2009 David Gageot 4 comments

I’ve just posted a Google Spreadsheet to list java frameworks and libraries supported by Google App Engine : http://spreadsheets.google.com/pub?key=pRJ_0hajVrhacLjp3HqD5ew

appengine_lowres

Feel free to update and share.

Google Moderator on Coding Style Preferences

April 10th, 2009 David Gageot Comments off

I’ve just started a Google Moderator on Coding styles. The idea is to find which coding style preferences are accepted by the majority, which interest nobody and which are balanced between likers and haters.
spaghetti2lq9

Google Moderator is not the perfect platform for this kind of experiment (no code formatting, no urls…) but I wanted to give it a try.

Feel free to add a lot more questions.