J2EE Dangers - - Excerpts

Powered by Qumana

From: http://www.javaworld.com/javaworld/jw-03-2001/jw-0330-ten.html?page=2

Vendor Sel: 1,5

Desgin: 2,3,7,10   -  1,5

Dev: 6,8,9   -  1,2,3,5,7

Stabilization/Load Testing :   -1,2,3,5,6,7,9

Live: 4 - almost everything

1. Not understanding Java, not understanding EJB, not understanding J2EE

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

.Not understanding J2EE

Symptoms:

• The "Everything is an EJB" design


• Manual transaction management instead of using the container-provided mechanisms


• Custom security implementations -- the J2EE platform has probably the most complete and integrated security architecture in enterprise computing, from presentation right through to the back end; it is rarely used to its full capabilities

2. Over-engineering (to EJB or not to EJB)

Symptoms:

• Oversized EJBs


• Developers who can't explain what their EJBs do and the relationships among them


• Nonreusable EJBs, components, or services when they should be


• EJBs starting new transactions when an existing transaction will do


• Data isolation levels set too high (in an attempt to be safe)

3.Not separating presentation logic from business logic

4.Not deploying where you develop

Also, get a snapshot of data from the production database and use it for testing, don't rely on artificially created data. If production data is sensitive, desensitize it and load it up.

5. Choosing the wrong vendors

Poor or zero integration between different tools (application servers and IDEs, IDEs and debuggers, source control and build tools, the list goes on)

For IDEs, debuggers, etc., developers simply forsaking them in favor of their own favorite tools

6. Not knowing your vendors

To avoid the dangers resulting from not knowing your vendors, subscribe to all the vendor-supplied support resources you can find such as email lists, news groups, and release notes (especially those with a list of bug fixes); you will get invaluable information.

Create a BUILD process well in advance

How transferable are vendor-specific skills in the J2EE world? Let's look at a concrete example of how two vendors -- IBM and BEA Systems Inc. -- that support EJB 1.1 produce dissimilar application servers. Indeed, how alike are BEA WebLogic 5.1 and IBM WebSphere 3.5?

1. BEA WebLogic is configured and administered in a completely different manner than IBM WebSphere.


2. IBM adopted an all-GUI environment philosophy with WebSphere. In contrast, BEA provided a whole host of command line utilities with WebLogic.


3. IBM WebSphere uses IIOP to communicate and throws CORBA exceptions that are visible to the programmer; WebLogic has no CORBA infrastructure at all, and uses the t3 protocol by default.


4. WebSphere is joined at the hip with Visual Age, while WebLogic is more IDE-agnostic. Indeed, you can develop for WebLogic using almost any IDE.

Being an expert on one application server does not mean you are an expert on all. The arguments above apply to anything: IDEs, debuggers, build tools, configuration management, and so on. . As such, allow yourself the time required to be skilled with your tools.

7.Not designing for scalability or performance

With Danger 7, close in on your performance and scalability requirements in the scoping phase -- know what numbers you need to hit before you move into development. If you know you need 50 transactions per second and your all-entity bean design will provide only 40, then you need to look at alternative solutions such as stored procedures, batch processes, or reworked OLTP aspects of your system.

Involve your vendor as much as possible in the scaling requirements -- they should know the strong and weak characteristics of their product and help you accordingly.

8.Antiquated development processes

use a well defined methodology. ensure build process is in place.

Good unit testing in placeTags: J2EE java pitfalls dangers

9.Failure to employ frameworks

+ no logging standards, bad exception handling framework

The following tasks are handled in a myriad of ways by developers and should be among the first targets of any framework:

• Logging


• Exception handling


• Getting a connection to a resource (database, naming service, and so on)


• Building JSP pages


• Data validation

Basing project plans and designs on marketing blurb, not on technical fact