1. It doesn't matter what data store type you use.

One of the first steps in designing an application is to decide on
the data store. It used to be that every application was based upon a
database, and this was simply not an issue. However, there has recently
been an upsurge in additional options: you can now use relational
databases, XML databases, object databases, directory servers, and more.




Instead of this approach, it is possible to devise a method where
your own beans handle this numbering. By putting the code into your
beans, and removing it from the vendor-domain, you suddenly are back to
vendor-neutrality, flexibility, and even (in many cases) better
performance. If you check out my book, I'll give you the exact
code to handle this specific case, and show you in detail how to avoid
these vendor-specific problems.

3. I need an editor or tool to write my Enterprise JavaBeans.

I'm often asked about the tools that I use in my EJBs. Specifically,
people want to know what I use to generate my remote interface, home
interface, and implementation-class source code. The idea is that there
is so much repeated code in these components that you have to have a
tool in order to make things easier. The mistake creeps in when you go
in and modify these skeletons, and miss a spot here, or accidentally
foul up a method signature there. The result is code that fails
compilation and is often hard to debug.

Now maybe it's just that I cut my teeth on Java using vi and
notepad, but I'm content with Ctrl+C and Ctrl+V, and 'yy', 'dd', and
'p'. Cutting and pasting in these text editors has kept me much better
off than any editor or tool ever has. It also generally results in me
understanding my code better, and knowing exactly where everything in
my code is.

I'm not saying that you shouldn't use an editor or a tool (I often use jEdit.);
however, as soon as you depend
on those tools, you're in trouble. Take a week to code in nothing but a
text editor, and you'll be amazed at how reacquainted you manage to get
with your code. Of course, my book assumes no such tools, and it walks
you through the exact process that results in efficient, logical coding
of beans, as well as other components in your application.

4. I've got to include JMS, XML, JAXP, and more in every application.

I realize that if you¢ve been reading my books and articles for very
long, you¢re probably tired of this sort of thing. I'm constantly
harping on programmers, insisting that they only use what they need in
their programs. However, until I see people get over their
technology-lust, I'll keep hollering about this one.

The basic mistake I'm referring to is the thinking that everything
in J2EE must be used in a J2EE application. If that application doesn't
use EJBs, JMS, JMX, XML, and every other acronym on the package of your
application server, you think you're somehow wasting money.

Nothing could be further from the truth, though. In fact, in my
latest book, I had to almost force in a chapter on JMS (the Java
Message Service). This isn't because JMS isn't important; it's simply
that the application I was writing for the book didn't really need JMS
that much. I have written several applications that do use JMS, and I
was able to come up with a pretty good use-case for JMS in the book.
However, that situation is a perfect illustration of the issue:
sometimes you just don't need the whole kitchen sink.

In any case, for about the 50th time, you should only use what you
need. If all that is required is a couple of servlets and some JDBC
code, then stick with that; don't add the complexity of EJBs if you
don't need it. If you need EJBs, but message-driven beans are beyond
the scope of your application, don't worry about it. In the long run,
you'll appreciate the resulting simplicity of your application.

5. Stateful beans make programming more object-oriented.

This is a common one, and usually an easy one to correct. The basic
mistake involves the way that methods are called. For example, here's a
few methods that you might find in a stateful session bean's remote
interface:



The thinking is that you need to make this a stateful session bean so that you
can pass in the username only one time (in the create() method). So your method
calls would look like this:


This is more object-oriented than using a stateful bean, which has methods more
like this:


The result is that the same code block would look like this:



Wow! It's obvious that this is so much harder to understand
and work with. (OK, that was a bit sarcastic; print is such a hard
medium to get clever in.) As you can see, this may not be quite as OO
(object-oriented). However, you'll find that changing to the stateless
approach (shown second) results in a speed up to the tune of 10 times
or sometimes even 100 times faster (depending on the application
server). So for this rather small sacrifice in OO coding results in
your code speeding up dramatically. One more mistake dealt with and out
of the way.

6. I don't need anyone telling me what to do in my programming.

Ah, yes. We've all been there, right? I remember my first few years of
programming when I knew
that I was going to always innovate, always create, never copy, and
never need any help. Of course, I later found out that most of my
clever "innovations" were poor solutions to well-understood problems,
many with established "best-case" solutions. It's absurd to be so
egotistical as to refuse to accept help when it's offered.

Is this a shameless plug for my book? No, not really. I'd advise you
to go out and get anything you can find on the subjects you are working
in. Heck, I have nearly as many non-O'Reilly technical books as I do
O'Reilly books, and I use my whole library all the time.

I'd also recommend you get involved in the open source community.
You'll learn more than you could ever imagine. The bottom line is that
there are a lot of really bright people out there, and I'd suggest you
suck all the knowledge from these folks that you can. As soon as you
decide that you don't need anyone else's help, you'll certainly begin
to make more mistakes than ever.

Well, there are six common problems I see cropping up time and time
again. You may see one or two in this list that you yourself have
ascribed to. Don't feel embarrassed; I've been guilty of all of these
at one time or another, but I got over it. Just take them as spurs to
make you a better programmer. I hope you enjoy the new book, and I look
forward to hearing what you think. See you online!
My Blogcopied Six Common Enterprise Programming Mistakes


other resources
Common C Programming Errors
What's wrong with my program - Common Programming Mistakes
Welcome to the Java Mistakes Page!
Top Ten Errors Java Programmers Make
common java syntax error