Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

J2EE project dangers!

Avoid these 10 J2EE dangers to ensure your enterprise Java project's success

By Humphrey Sheil, JavaWorld.com, 03/30/01

Page 2 of 8

Figure 1. Enterprise Java project phases
and their most likely reasons for failure.
Click on thumbnail to view full-size
image. (60 KB)

Well then, without further ado, let's dive right into the top 10!

Danger 1: Not understanding Java, not understanding EJB, not understanding J2EE

Right, I'm going to break this one into three subelements for easier analysis.

Description: Not understanding Java

Project phase:

Development

Project phase(s) affected:

Design, Stabilization, Live

System characteristics affected:

Maintainability, scalability, performance

Symptoms:

• Reimplementing functionality and classes already contained in the JDK core APIs
• Not knowing what any or all of the following are and what they do (this list represents just a sample of topics):
  • Garbage collector (train, generational, incremental, synchronous, asynchronous)
  • When objects can be garbage collected -- dangling references
  • Inheritance mechanisms used (and their tradeoffs) in Java
  • Method over-riding and over-loading
  • Why java.lang.String (substitute your favorite class here!) proves bad for performance
  • Pass-by reference semantics of Java (versus pass-by value semantics in EJB)
  • Using == versus implementing the equals() method for nonprimitives
  • How Java schedules threads on different platforms (for example, pre-emptive or not)
  • Green threads versus native threads
  • Hotspot (and why old performance tuning techniques negate Hotspot optimizations)
  • The JIT and when good JITs go bad (unset JAVA_COMPILER and your code runs just fine, etc.)
  • The Collections API
  • RMI

Solution:

You need to improve your knowledge of Java, especially its strengths and weaknesses. Java exists far beyond just the language. It's equally important to understand the platform (JDK and tools). Concretely, you should become certified as a Java programmer if you aren't already -- you'll be amazed how much you didn't know. Even better, do it as part of a group and push one another. It's also more fun this way. Further, set up a mailing list devoted to Java technology and keep it going! (Every company I have worked with has these lists, most of which are on life-support due to inactivity.) Learn from your peer developers -- they're your best resource.

Notes:

If you or other members of your team do not understand the programming language and the platform, how can you hope to build a successful enterprise Java application? Strong Java programmers take to EJB and the J2EE like ducks to water. In contrast, poor or inexperienced programmers will construct poor-quality J2EE applications.

Description: Not understanding EJB

Project phase:

Design

Project phase(s) affected:

Development, Stabilization

System characteristics affected:

Maintenance

Symptoms:

• EJBs that work when they are first called but never thereafter (especially stateless session beans that are returned to the ready pool)
• Nonreusable EJBs
• Not knowing for what the developer is responsible, compared with what the container provides
• EJBs that do not correspond to the specification (fire threads, load native libraries, attempt to perform I/O, and so on)

Solution:

To improve your EJB knowledge, take a weekend and read the EJB specification (the 1.1 version is 314 pages long). Then read the 2.0 specification (524 pages!) to get a feel for what the 1.1 specification didn't address and where the 2.0 specification will take you. Concentrate on the parts of the specification that tell you, the application developer, what are legal actions in an EJB. Sections 18.1 and 18.2 are good places to start.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.