Java EE Best Practices Updated

Posted by Rob Thornton on Feb 16, 2007

Sections

Development,

Architecture & Design

Topics

Programming ,

Java

Tags

Best Practices ,

Java EE

Share |

IBM has updated a 2004 article on Java EE best practices, compiling a list of 19 practices. They range from always use MVC to prefer JSPs as your first choice of presentation technology.

The article is an updated version of one published in IBM’s WebSphere Developer Technical Journal in 2004. They’ve updated it to include current technology and they include practices that the authors consider standard but are not always followed. Number two on the list is: “Don’t reinvent the wheel. Use common, proven frameworks like Apache Struts, JavaServer Faces, and Eclipse RCP. Use proven patterns.” They expected frameworks like Struts to replace homegrown MVC frameworks, however they say:

What has proven surprising is that this has turned out to not be the case. We still see many companies maintaining or even developing new user-interface frameworks that are functionally equivalent to Struts or JSF. There are many reasons why this could be true: organizational inertia, “not invented here” syndrome, lack of perceived benefit in changing working code, or possibly even a slight sense of hubris in thinking that you could do things “better” than the open-source developers did in a particular framework.

However, the time is long-past when any of these reasons is worth using as an excuse not to adopt a standard framework.

The complete list of practices is:

1. Always use MVC.
2. Don’t reinvent the wheel.
3. Apply automated unit tests and test harnesses at every layer.
4. Develop to the specifications, not the application server.
5. Plan for using Java EE security from Day One.
6. Build what you know.
7. Always use session facades whenever you use EJB components.
8. Use stateless session beans instead of stateful session beans.
9. Use container-managed transactions.
10. Prefer JSPs as your first choice of presentation technology.
11. When using HttpSessions, store only as much state as you need for the current business transaction and no more.
12. Take advantage of application server features that do not require your code to be modified.
13. Play nice within existing environments.
14. Embrace the qualities of service provided by the application server environment.
15. Embrace Java EE, don’t fake it.
16. Plan for version updates.
17. At all points of interest in your code, log your program state using a standard logging framework.
18. Always clean up after yourself.
19. Follow rigorous procedures for development and testing.

1. Back to top

   Best practices? I don't think so.

   by Andrew Swan

   Reading this article made me feel disillusioned and a little bit angry. Much of the article, where the author sticks to non-product guidance like "layer your app" is good. But several of the technology-specific tips are misguided at best. For example:
   
   1. It implies that the only viable view technologies are JSP and XML/XSL. What about the excellent Velocity and FreeMarker templating engines? They are great for preventing developers from embedding business and controller logic in views.
   
   2. Use Struts? Maybe five years ago before Spring MVC came out. Spring's offering is so much more testable, extensible, and decoupled. I don't know much about Spring Web Flow, but it may be even better still, certainly for web workflows of any complexity.
   
   3. Use Cactus to test J2EE components? I admit to doing this myself before seeing the light on POJOs. Write your application using POJOs, and you can test them using plain old JUnit without complicated and slow in-container testing. Then wrap them in a trivial EJB if you need to (although with a DI container like Spring you usually don't even need that).
   
   4. Use J2EE security for authorisation? For most real-world apps, where access is per-entity based on complicated criteria, it's useless (ref: www.owasp.org/index.php/Access_Control_In_Your_...). JAAS is only good for authentication. So overall, you're better off using a pluggable security framework like Acegi for both these aspects of security (are there any real alternatives?).
   
   5. The article says to code to the EJB spec, not the app server, then goes on to list all the WebSphere features to enable. Is this a J2EE article or an IBM sales pitch? Ever heard of JBoss?
   
   6. Use entity beans? This is where the article really lost any credibility. No, use the DAO pattern, and implement your DAOs using either direct JDBC or better still, an ORM tool like Hibernate. How can a best practices doc not mention this amazing product?
   
   7. Use a logging framework like JDK 1.4 logging or Log4J? At runtime, sure. But please only use the Jakarta Commons Logging API within your code; this isolates your app from the actual logging implementation used in deployment.
   
   8. Always clean up after yourself. Good advice, but better still is to use a framework that cleans up automatically. For example, if using JDBC, use Spring's JdbcOperations API to avoid any possibility of Connections, PreparedStatements, or ResultSets being left open by developers.

   Reply

2. Back to top

   JEE Best practices

   by JAVAID ASLAM

   The pracice
   Use stateless session beans instead of stateful session beans,
   seems to be very naive. The J2EE patterns (Sun's Pub.)book
   explains when and when not to use satefull session. I have not found any blanket justification for always using the stateless session beans.

   Reply

3. Back to top

   Ulterior motives?

   by Bill Siggelkow

   I have not read the article, only the synopsis here. However, it occurs to me that the author may be not-so-secretly conspiring to keep developers from moving off Websphere.

   Reply

4. Back to top

   Re: Best practices? I don't think so.

   by Lucky Luke

   Andrew, You kinda missed the point of the best practices article.
   Also, you emphasised only a part of what they wrote and deliberately(?) missed the other part.
   

   
   1. It implies that the only viable view technologies are JSP and XML/XSL. What about the excellent Velocity and FreeMarker templating engines? They are great for preventing developers from embedding business and controller logic in views.
   

   
   Of course you're right, there are more view technologies, but as you say, templating engines you refer to do the work for you, embedding business and controller logic in views. So, using MVC is a very good idea, apart from the technology you use, isn't it?
   
   

   
   2. Use Struts? Maybe five years ago before Spring MVC came out. Spring's offering is so much more testable, extensible, and decoupled. I don't know much about Spring Web Flow, but it may be even better still, certainly for web workflows of any complexity.
   

   
   You omitted the other part of the sentence ('Use Struts, Java Server Faces ...').
   I personally think that JSF is a very promising technology. (with great frameworks like Seam gaining momentum).
   

   
   3. Use Cactus to test J2EE components? I admit to doing this myself before seeing the light on POJOs. Write your application using POJOs, and you can test them using plain old JUnit without complicated and slow in-container testing. Then wrap them in a trivial EJB if you need to (although with a DI container like Spring you usually don't even need that).
   

   
   Once again, the whole sentence used in the article says you should use Cactus OR JUnit. You can't just cut some words out ;-)
   

   
   4. Use J2EE security for authorisation? For most real-world apps, where access is per-entity based on complicated criteria, it's useless (ref: www.owasp.org/index.php/Access_Control_In_Your_...). JAAS is only good for authentication. So overall, you're better off using a pluggable security framework like Acegi for both these aspects of security (are there any real alternatives?).
   

   
   Of course, Acegi is often very good solution for security. But, I don't know where you tried to use Jaas in commercial application. I did, and I can say, that there are many possibilites there. You can write your own security realms and that allows you to use as sophisticated criteria as you want. I can't say it's easy, though.
   

   
   5. The article says to code to the EJB spec, not the app server, then goes on to list all the WebSphere features to enable. Is this a J2EE article or an IBM sales pitch? Ever heard of JBoss?
   

   
   Point taken, sounds like a sales pitch ;-).
   

   
   6. Use entity beans? This is where the article really lost any credibility. No, use the DAO pattern, and implement your DAOs using either direct JDBC or better still, an ORM tool like Hibernate. How can a best practices doc not mention this amazing product?
   

   
   Have you used the Java Persistance API and it's entity beans recently? It's very similar to Hibernate. In fact, you can use Hibernate as the JPA implementation provider. I also think that is has a big advantage over hibernate - it's standarised in the JEE 5 specification.
   

   
   7. Use a logging framework like JDK 1.4 logging or Log4J? At runtime, sure. But please only use the Jakarta Commons Logging API within your code; this isolates your app from the actual logging implementation used in deployment.
   

   
   Maybe I've some old habits, but I always used log4j for logging... Well, I'll try the commons logging :-).
   

   
   8. Always clean up after yourself. Good advice, but better still is to use a framework that cleans up automatically. For example, if using JDBC, use Spring's JdbcOperations API to avoid any possibility of Connections, PreparedStatements, or ResultSets being left open by developers.
   

   
   Well, they didn't write anywhere that you can't use anything to clean up for you ;-)
   Regargs,
   Luke

   Reply

• Older >