I was reading Steve Yegge post about size being the enemy of code and totally agree. There is a section where he talks about Design Patterns adding a huge amount of bloat to a code base, I don't totally agree with that but it did get me thinking about use of Design Patterns in Java APIs.
Something went wrong with the Java community in the late 90s when Design Pattern "inspired" APIs came out in droves. All good ideas can be misused - but Design Patterns have to be the top of the heap.
The APIs before that were really nice and simple to use. It was great in Java 1.0 to be able to say
vector.remove( item )
and not the C++ STL version of
invalid = remove( vector.begin(), vector.end(), item );
vector.erase( invalid, vector.end );
Somewhere around Java 1.2 coming out a whole batch of really bad APIs came out, and everyone from then on modelled after the bad APIs. As an example I'm going to use JavaTV. What do you think the API to change a channel using JavaTV would be?
tuner.changeChannel( newChannel ) ?
Of course not, that would be too easy and not employ enough Design Patterns. What you actually have to do is:
ServiceContext sc = ServiceContextFactory.getInstance().getServiceContext( xletContext );
Locator channelLocator = LocatorFactory.createLocator( "ocap://0x213+0x110" );
Service channel = SIManager.createInstance().getService( channelLocator );
sc.select( channel );
Thats 1 FactoryMethod, 2 AbstractFactories and 2 Singletons - that's an impressive set of Design Pattern use. If you think that's an isolated case think again. Just look at the XML APIs, Security APIs, Java Media Framework, etc, etc.
So, in short Steve is right, but it doesn't have to be that way. Java doesn't need to spend 10 lines saying what other languages can say in 1. It just needs more care spent with API design.