Link Details

I see the point he is making but this is not what I mean when I talk about verbosity

I'm talking about having to write a whole new class to create a simple closure. Having to write a foreach or a iterator to step through a collection and about having to repeat each type at least twice once for the reference and once for the construction.

Java is a verbose language to get things done it, that's common knowledge to anyone who works in multiple languages. Java verbosity is a result of the language grammar and lack of innovation over the years, hampered by it's conservative backwards compatibility politics. Read the language spec and historic evidence [http://java.sun.com/docs/white/delegates.html]. Just to mention a concrete example, it took a decade for us to get Enum's in the language rather than having to emulate them through patterns.

The kind of verbosity *I* care about *is* Java's fault. I can *fix* API issues; I can't fix the underlying model of abstraction (or lack thereof).

Or as I said in that blog's comments, Java's verbosity is also *our* fault.

http://chriswongdevblog.blogspot.com/2010/01/lets-get-rid-of-middle-management.html

Don't want to be impolite but scanning the article I get the impression you have no idea what loose coupling and modular programming is about. Interfaces are in no way boilerplate code. Bad thing about Java and this is another thing that makes it verbose is the fact that interfaces cannot contain implementation code. You have to reimplement the interface on each instance it is created on even though the code stays the same across implementation. This results in nasty static utility classes.

Maybe you should do more than scan the article. I have been developing the Java enterprise way for years, and have been following the usual "best practices" all this time. Now I am questioning them. The habit of slapping unnecessary interfaces on everything in sight has not really paid off for me. It will take more than throwing around buzzwords like "loose coupling" and "modular programming" to convince me at this point that "middle management" code is necessary.

First of it is good to question "best practice" as using them blindly leads to bad code! First and most important credo for any developer is THINK!
Ok now that I got that out of the way let me tell you that I'm not throwing buzz words around but concrete experience in my everyday job programming enterprise apps. And yes I've been doing this for several years.
A interface basically gives you a natural border for interaction between the client and the implementation. When you change the implementation around your change only travels as far as the interface and no further so your clients do not need to change. This effectively shields your clients from change and introduction of subtle bugs and makes the implementation reusable across your app and sometime even beyond.
Does this mean you should use interfaces in all places? Certainly not but using a concrete ArrayList instead of List is a sure way to ruin somebodies day when he has to come back to your code after a couple of years and change all places to LinkedList because measurements show that LinkedList is a better solution to the problem. You have effectively produced tons of waste... and made a poor guy very unhappy questioning why he ever wanted to become a programmer.
As a side note introducing an interface makes you think about the contract between your implementation and the rest of the world.

So please do not accuse me of being unexperienced or using buzz words just for the sake of it.

Thanks for responding, but I don't see what exactly you are trying to tell me. I never said that interfaces were bad. I was questioning the overuse of unnecessary interfaces in Java enterprise programming. I explained why they were unnecessary. I know what interfaces are for and am not interested in discussing them at the Java beginner's level. Now, if you want to address the arguments in my blog you are welcome to do so. I can't tell if you read it. But talking about the merits of interfaces in general is too generic to be interesting.

A layer is nothing more then a interface on a service level. So each layer introduces an indirection which shields the layer above it from the implementation details of the layer below it. Now exchange AbstractList and LinkedList with Layer1 and Layer2 and we are where we started.

I give you one credit in that excessive use of layers is not a good thing but the example you are giving is basically to use the persistence manager directly form your business logic. This in effect makes your business logic depend on your persistence layer making it hard to reuse in other places where the persistence layer can be different. For a concrete example I'm currently maintaining a code base which is about 8 years old. Since technology has vastly advanced we need to upgrade the persistence technology effectively swapping out old code. Thank god we have a dao layer as this means we only have to exchange the persistence layer and do not have to change any business logic. Would we have not had the dao layer we would have to do a whole lot more.

Layers separate functionality: view, service, persistence etc. But layers do not need that Java construct we call interfaces. A Java "interface" slapped on top of true implementations, I would argue buys us nothing. You can have a layered architecture without interfaces. Even the classes you cited -- AbstractList and LinkedList -- are not interfaces per se. Yet Spring best practice tells me to slap an interface on top of everything. That is the point I was trying to make: why introduce interfaces when you don't need one?

I questioned everything, but that does not mean I personally go that minimalist. While I agree that a separate persistence layer is a good thing, that particular example is too small to justify it. After all, how hard is it to substitute an implementation of session.get()? Is it really easier to write a separate DAO for every persistence class instead of just session.get()? While I think separating persistence operations is a good thing, I also think the specific DAO pattern fits poorly in the context of POJO-based persistence, and I gave my reasons.