Oh and I’m not saying database changes never happen but you have to admit, most of the time the schema changes the code has to be changed anyway. It’s rare to change a database schema and XML mapping file for entities, without changing a line of code. The only example that even comes to mind is when you rename a column.

E.g., XDoclet was around long before Hibernate et al. ever existed, and it took a lot of the pain of maintaining the various source and config files out of EJB. But either way, I wouldn’t say that having one or two large config files is an unworkable situation; it presents some organizational challenges, and isn’t pretty to begin with, but just like 100KB Struts config files, people have learned to live with it. For sure, annotations are nicer, but EJBs were cooked up during the Java 1.2 lifetime (originally in 1998, I think).

As to the database changing w/o the app code changing, oh yes, it happens. I’ve seen weekly schema changes is huge databases, when only a single one out of the many apps running on the DB was changing. That’s were abstraction layers really help. Generally, the code and config files needed for those can be created (semi-)automatically, in which case it doesn’t matter much how large they are.

In my view, the main problem had more to do with getting EJB apps to scale well without throwing a lof of hardware at it (add comment about Sun being a hardware vendor here), and that EJB servers were too expensive to be used lightly by small companies. It was far cheaper to run a servlet container using JDBC plus some homegrown ORM solution, and implement other app server functionalities as needed.

I have ventured only into the shallows of EJB, but I could see the deep water. This murkiness is not a unique situation. I have seen theory raise its ugly head and squash practicality several times. I saw it happen in my specialty are, languages, as far back as PL/I. It repeated itself with Ada, and others. And, I fear, it’s beginning to happen in the later versions of Java. But that’s a different subject.

Your explanation is a delight to read. Perhaps enough of your type of thinking will cause a return to reality and practicality.

While users usually don’t care about that, it still is important to use proper names for tables and columns in the same way it is important to use proper names for your classes, methods, etc.

Why? Because it makes it easier to comprehend the system , to maintain it. And when you directly use SQL/JDBC in your code or use annotations (XDoclet or Java 5) to map your classes and their fields to their corresponding tables and columns respectively, using proper names makes your code more readable to.