I think there is something wrong here. We have thousands of classes and hundreds of packages, but import lists are rarely more than about twenty lines. Many classes will interact with a huge number of other classes, but these are covered by a relatively small number of interfaces.
e.g. looking at java packages, many classes need 5 lines just importing the IO packages (io, net, nio*3)
e.g. every method that implements (or overrides an implementation) of an interface that throws a package-specific Exception then needs that package; in java.* the most common occurrences I tend to see are SQLException and IOException.
Going back to the non-java classes, a game server project I have in my workspace right now has over 200 classes (this is for a small/simple game). Not unreasonably, that's partitioned into 12 direct packages (mostly sub-packages), and a further 4 packages which are dedicated to overriding particular behaviour from particular implementations of particular 3rd party libs (i.e. the libs could realistically be replaced by any of 2 or 3 alternatives, invalidating all the overrides; we need to be able to easily ignore those overrides - placing them in one package (and a stand-alone JAR) makes this easy; any suggestions for a better way would be appreciated, but I think we've tried pretty much everything at least once already
Now, that's not including ANY of the packages that have to be imported from other products / 3rd party libs. At the moment, this small game is using 3 different external products, one of which alone has about 15 packages (although one of the others only has one package for the whole product...). Using that product - which is a base engine - means frequently importing 5-10 different subpackages; since it has dependencies on yet more libs, sometimes (depending upon your game, and what bits of the engine you're using) you need to import considerably more.
Personally, I would absolutely love to see java have a recursive import; I'd be even happier if the naming system got "upgraded" into making use of the implicit hierarchies. I've always found it suprising that java uses a hierarchical naming system, but explicitly states there is no actual hierarchy - the fact that A is a subpackage of B has no meaning in java. I consider this to be wrapped up with the miserable lack of any serious package-management in JAR and packages; it appears that whoever did these parts of java originally either had little knowledge of management systems, or far too little resources and was forced to design and spec something almost entirely useless.
The java world would be a far, far better place if it had a "real" package management system. The present hacks to the JAR spec to make it allow primitive naming and versioning are far from adequate. In fact, in a recent mailing list discussion about "deploying complex systems" I had to warn someone off java simply because they'd have to spend months re-inventing the wheel and writing their own (unless they were happy to do this..).
<gets off soapbox>