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.

As a result, many companies have begun to interchange these different data stores, often without any real thought. If a directory server is cheaper than a database, it is used to replace the database. XML databases are put in place because they are "sexy" and satisfy "technology lust." However, the trend to use any data store for any case is simply absurd; your performance will began to degrade, your code will become overly complex, and you'll have no idea why.

Each data store has a specific purpose. For example, directory servers are optimized for frequent reads, with few writes. Authentication and searching for names and addresses is a perfect usage of a directory server. However, if you start to add  data programmatically to a directory server often, you¢ll see a degradation in performance. A database is better in this case.

The same sort of choices are important when determining what kind of database to use. For example, using an XML database in an application that never pulls XML directly out of that database is silly. You're choosing a technology (XML), and then never using that technology.

In my new book, I detail these exact choices. (Yes, it's more than just a book about Java.) In fact, you'll learn how to integrate databases and directory servers into the same application, and even how to transfer data back and forth between them.

2. Vendor-specific programming  speeds up programming tasks.
Far too often, programmers take shortcuts to write code faster. However, more often than not, these "shortcuts" turn into long-term pitfalls. No matter how much time this may save a programmer up front, it will always end up taking more time in the long run to undo and redo correctly. Let me give you an example.

Take the issue of working with Enterprise JavaBeans (EJB) and database tables. A common  issue is inserting a number into the ID field of a table. Because Oracle uses sequences to allow this, MySQL uses an auto-increment field, and other tables may not provide any numbering facility at all.

What I see, time and time again, is code in an EJB that directly accesses that Oracle sequence, or MySQL incremented field, or any other database. In other words, these EJBs would not work on any database but the one they were coded to; in fact, they often won't work with different versions of the same vendor's database. The result is a non-portable, short-lived piece of code that won't be able to keep up with the changes of your company.

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:

  public User create(String username);
  public Address getAddress();
  public List getAccounts();
  public boolean deleteAccount(Account account);

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:

  User user = userHome.create(username);
  Address address = user.getAddress();
  List accounts = user.getAccounts();

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

  public User create();
  public Address getAddress(String username);
  public List getAccounts(String username);
  public boolean deleteAccount(String username, Account account); 
The result is that the same code block would look like this:

User user = userHome.create();
Address address = user.getAddress(username);
List accounts = user.getAccounts(username);

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.