I'm growing increasingly fustrated with the removal of some of the best features of Java. Namely type safety.
More and more we are getting these configuration driven frameworks where objects are cast to their correct types willy nilly. The idea behind these systems is "a non developer can reconfigure the application without touching code". This is just dumb. There is no way a non-developer can edit a half-megabyte Spring configuration and know what they are doing. Even developers are having a hard time with it. Next, since its just a bunch of xml, typos can cause huge problems that are not discovered until runtime. And sometimes not till a certain piece of code is executed.

We are creating defacto programming languages with these configurations that only the application developers can understand. We are losing the benefit of a compiler to tell us if the object we are pointing to exists. Even in the code, we are losing type safety as the objects handed from the framework are cast to the correct type.

Worse of all, people keep saying "its more object oriented". This is just incorrect. It does make the code more abstract but, this is really a farse since objects must be cast before they can be used. About the only thing it is really good for is enforcing developers to code to interfaces instead of implementation classes.

I got started on this rant in the process of migrating a rather large code base from Hibernate 2 to version 3. I must clarify that I was using a patched version of Hibernate 2. This patched allowed one to call count on a criteria object. So my pagination code basically called:
List results = criteria.list(); // get a page of results
long totalCount = criteria.count(); // get the toatl count
The criteria had criterion added to it to restrict the results for a page of data.
The Hibernate developers decided that its more convienent for me to get the count with:
Integer count = (Integer)criteria.setProjection(Projections.rowCount()).uniqueResult();
int total = count.intValue();
So now instead of the safety of a method that returned a long. We have a method that returns an Object. We *know* the Object is an Integer because we passed Projections.rowCount() to the object that we passed to the criteria, and we cast it. So instead of the criteria interface getting bloated, every consumer of the library gets to have their code bloated. If the Hibernate code ever changes, you won't know until you run the code because of the cast. Suppose one fine day they decide to return a Long instead of an Integer. You'll get no compile error because the interface returns an Object. Instead of using the compiler to find the code that needs to change, you'll have to grep for it (unless you use windows, then your life will suck).

Any developer who has spent time using the Spring framework can tell you how much time they've wasted because they have to start the application to find errors in the configuration.

How about we start writing configuration classes. Actual compilable code to configure the application. Return actual objects instead of strings. Return actual types and not just Object. Drop construction via reflection. Non developers are not going to be able to reliably configure your application anyway. Create a configuration package. All of the config classes can go in there. If anything is wrong, you get a compile error. No more spending an hour debugging just to find a typo in hte config (the config), hehe.

Finally, a word regarding setter injection so loved by Spring aficionados. If the object passed in a setter to an object is required to make it function, then get rid of the setter method and pass it to the constructor. How else can anyone know that a required thing is missing?

Final word, I am not finished with this subject.