JMockit is another toolkit which allows mocking of static methods (as well as final methods, constructors, etc.).
I don't see any problem with the judicious use of static methods when designing an otherwise OO solution.
For example, one pattern/idiom I like to use is the static facade, particularly to provide a simpler and easier to use API to the persistence subsystem in a business application. In my opinion, no other solution is more elegant than something like:
List<Person> peopleAboveAge =
find("select p from Person p where p.age >= ?", age);
where the find
method is statically imported from a PersistenceFacade
class which defines only static methods, and encapsulates how to obtain the proper Session/EntityManager instance. This solution is unit-testing friendly and flexible. I used it in a business application which had 500+ persistent entities, using Hibernate. The static facade helped when we migrated from Hibernate 2 to Hibernate 3, when we migrated from Oracle to Sybase and then back to Oracle, and when we started using JPA annotations instead of "hbm.xml" files for ORM mapping.