What are some common anti-patterns in Java architecture? Are there any particularly egregious ones? Also, are there some 'common wisdom' or 'best practices' architectural patterns being implemented by Java development teams that are in reality anti-patterns?
That's a really interesting question, and I'm sure the community at large would have a lot to say about this. In terms of modularity, the one thing I've always found fascinating is that we spend a lot of time on the design activity. In most cases, we focus on class design and apply object-oriented principles and patterns. We try to create this structurally resilient and flexible piece of software. But then we package everything into a single deployable unit (WAR or EAR) and deploy it and essentially forego a lot of the flexibility we're striving for (i.e., unit of reuse equals the unit of release). Even the smallest change to the software requires that we build, test, and deploy the entire system. That's an anti-pattern. With a modular architecture, we can isolate change to a specific module, only build the module(s) that's changed, and then with a good module framework, only deploy the system modules that have changed. This level of dynamicity increases architectural agility.
Another I can think of is our failure to "architect all the way down", as I talk about in the book.
Visit the book's website at modularity.kirkk.com where you can review all 18 patterns and download an excerpt of the book. There is also a mobile web application available that you can take with you wherever you go.