Generics support for Apache commons collections

2009-05-16 22:30:00 +0200

In my day to day work program I use the Apache Commons library quite a lot.  One of those libraries is the commons collections library, of which I use the CollectionUtils class and ListUtils mostly. One great disadvantage of the commons collection library is lack of Java Generics support, added in Java 1.5.  This means if you call a function like predicatedList with a typed list and predicate argument, the function will return an untyped list. The list has to be cast again, which clutters up the code and doesn't look very nice, like the following example:

class Address {
    String firstName;
}

List 
myAddresses ; ... List
onlyJohns = (List
) ListUtils.predicatedList(myAddresses,new Predicate() { public boolean evaluate(Object o) { Address a=(Address)o; return a.firstName.equals("John"); } });

Quite a lot of casting as you can see in the above code. Less code would be needed if generics support would be added to the collection framework. Added generics support to the collections library should be too hard, and would improve my code.
I'd think other people would have that idea, and I quickly found the following posting on devx. Turns out there's a sourceforge project that has modified the collections library to have generics support: Commons Collections with generics.
The project is even added to the central maven repository, so to use the new collection library adding the following dependency is enough:

net.sourceforge.collections
collections-generic
4.01

The new code now becomes (excluding the Address class, which is the same):

List 
onlyJohns = ListUtils.predicatedList(myAddresses,new Predicate
() { @Override public boolean evaluate(Address a) { return a.firstName.equals("John"); } });

The code looks quite better! A lot less code would be needed if closures would be added to Java too, but that'll have to wait until JDK 1.8 or something is released.

Read more

Alternative to SQL

2009-05-04 15:55:57 +0200

Database alternative, for people just browsing and scanning, I'll write in staccato.

  • Relational model pretty good, but we need a better implementation of the relational model, SQL, at least the way it's used now, is just to primitive and cumbersome.
  • Lot's of new languages for the JVM, but we're still using SQL to retrieve data from databases. Many programmers may even think that is the only way to retrieve data!
  • ORM is worst of both world
    • Reinventing the wheel, caching, optimal data retrieval, query optimization
    • Relational model is more natural to retrieve data then object oriented model
    • Inheritence is not possible the way it's possible in OO, but same functionality is still possible.
  • Java Programmers are spending a LOT of time creating queries, doing optimization, thinking how to retrieve data. Java is improving, but SQL is just largely the same as it was 10 ago.
  • SQL / Database integration in Java is still poor. ORM frameworks just hide away the database - usually resulting in a lot of work for database administrators and programmer's just to tweak ill formed sql.

In short, where's a new language for the relation model and why isn't that language or technology emerging? What would be nice is:

  1. A better language to access a relation database, that doesn't involve lots of subqueries and joins to retrieve data.
  2. A database query langauge that is truly embedded in the programming language I daily work with (Java), and not hidden behind persistence managers, xml files,  application servers.  Or just as worse, SQL hidden in quoted string or text files.
  • For 1. After some searching, I found an alternative to SQL, Tutorial D.  The language isn't main stream, but is interesting to read about. Especially if you think SQL and (relational) databases are the same.
  • Also I heard a while ago about .QL on the 25 year anniversary of my university, but that's far from mainstream either.
  • For .Net there's LinQ, but that's little use for me as Java software developer.  At least Microsoft has a solution for 2.

Read more

Archive

subscribe via RSS