Adam Bien isn't without opinions when it comes to modern day enterprise programming techniques. From the use of design patterns, to the manner in which projects and modules are divided, Bien isn't without opinions when it comes to developing Java applications.

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.

Download this free guide

Download now: Java EE moves to the Eclipse Foundation

What are application developers and market analysts saying about Oracles decision to move Java EE to the Eclipse Foundation? What will this change? Find out here.

By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

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:

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.

Moving to a different language like Scala or Groovy isn't typically necessary for enterprises. You should just approach Java in a smarter way.

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.

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.

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.

1 comment

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Finally, a Java developer who understands what's important! I love the Java language, but I've worked with developers and architects who insist on code "elegance" at the expense of system usability, performance, and ease of maintenance. One of my coworkers described this practice as "coding stop lights in the desert". One of the interesting things is that the people who promote this "elegance" are often extremely bright people who have a way of convincing the masses that this is the only way to do it. They eventually get frustrated, leave the project or the company, and leave the rest of us to refactor the code so that it actually works for the customer.