With Java EE 7, your Design Patterns are dead. And your EAR is ugly too.

Sometimes, it's difficult to tell if Java Champion Adam Bien, the author of Java EE Night Hacks and Java EE Patterns, is an iconoclast or a cheerleader. On the one hand, he rarely has a bad thing to say about Java EE and the perpetual changes being made to the syntax of the language. Yet on the other hand, he's more than happy to challenge the community with regards to how they both currently, and in the past, approached the task of enterprise application development. Bien's attitude towards to various, sacred, enterprise programming design patterns is a prime example.

From my perspective, we should concentrate on business logic and forget about technology.

Adam Bien, Java Champion

Iconoclastically, Bien claims that most of the established J2EE and Gang of Four (GoF) patterns are no longer relevant for today's enterprise developers. He advocates for a continuous development style of development that rejects superfluous patterns and outdated best practices. It's lean, it's mean, and it's definitely opinionated.

"There are no patterns for Java EE6 or Java EE7. From my perspective, we should concentrate on business logic and forget about technology. In my JavaOne session, I put together an application from scratch, in an hour, demonstrating some best practices. I call it opinionated because it's an opinion. There may be other best practices, but this is my thinking of what an application should look like. Very simple, and very easy to build."

Here's a few more insights and opinions Bien has shared with us over the past year that tend to catch the ire of other advocates in the enterprise Java programming community:

1. Low productivity isn't a problem with the Java language, it is a problem with the architects who read a patterns book and apply it to their project whether it makes good sense or not. That's why they end up with 2% business logic and 98% bloat.
2. Moving to a different language like Scala or Groovy isn't typically necessary for enterprises. You should just approach Java in a smarter way.
3. Your system shouldn't be dependent on your IDE. Each developer should be able to choose whatever development environment they like. All the support you really need is coffee.
4. If you need a special assortment and wide gamut IDE plugins to be productive, that's a bad sign. Start NetBeans, fire up Maven build automation tool, and get to coding!
5. If you don't need it, get rid of it. That can apply to XML, extra plugins, whatever. Start lean, with a tiny POM. That's the number one way to ensure that later developers on the project understand what's going on behind the scenes. There should be no magic or black box development.
6. Don't be so anxious to divide and distribute code; WARs can be better than EARs when it comes to packaging; monolithic isn't always bad. Organizations don't need 500 modules since they won't be able to manage all the interfaces and interactions. Keep your code and your projects together until it becomes too big; then create a second monolith and let the two giants communicate via REST.

Of course, Adam doesn't just spout off opinionated Java without backing it up. At JavaOne, he not only advocated for his particular approach to development, but he also stepped through the development of a simple application that embraced his design ideals, all in less than an hour of time. Perhaps he's not an iconoclast. And perhaps its not fair to call him a cheerleader. Perhaps we'll just settle for what he calls himself: opinionated.