Hopefully more controversial programming opinions

Can you suggest any books?

I'm sorry, but your comment is really not much more than pointless, cynical Java bashing. Java has it's share of problems, and it's definitely not as modern (regarding language features) as some of the other languages today (although that seems to be changing too), but if you're going to attack it, then at least do it for it's bad characteristics, not because you personally dislike/don't understand certain features, or principles of OO development.

Design patterns- The art of bloating already heavily bloated code.

Design patterns are to OO code what salt is to food. Put just the right amount, and you get a tasty meal. Put too much, and you get an inedible pile of crap. Design patterns are not the problem, they are a solution. Bad developers who don't understand when and how to use them are the problem.

Love towards getters/settters and absolutely anything that lends to code bureaucracy.

It's true that Java is more bureaucratic than most languages, but there is a reason why getters and setters are the standard. And the reason is encapsulation. I can expand on this further if you want me to. For what it's worth, I think that this is one of the things that Scala got right [1].

Lengthen anything and everything as much as you can. thisIncludesTheVariableNames, Class names, methods names, package hierarchies, class inheritance. You name it they can pointlessly lengthen it.

CnfNfEx. ConfigurationFileNotFoundException.Which one of these two names do you think describes what the class does better?

If you write code in file at least 40% of the lines MUST be try/catch statements. If you can't be satisfied with that write your won exception classes and invoke point 5.

I don't know which APIs you worked with, but those that I use don't force me to put 40% of my code into try-catch statements.

Always write code which can't be read or figured out unless you have auto complete, intellisense and other IDE goodies.

I can see how autocomplete would make it easier to write code, but to read it? Nope, Java code is perfectly readable in a plain old editor, actually. But it's definitely not as easy to write using a plain old editor, to be perfectly honest.

Use XML as much as you can so that you can dogfood your insanity even more.

I agree with this one. XML madness needs to stop. Fortunately, it seems to be stopping already. For example, most modern DI frameworks don't require you to write your configuration in an XML file.

Make the code so verbose that even simple programs sound like very complicated ones that can be written only by you.

Verbosity is an unfortunate trait of Java. But nobody writes code so that it would seem that only they can write it. If they do, that's called over-engineering and is, believe it or not, considered to be a bad practice.

[1] http://www.dustinmartin.net/2009/10/getters-and-setters-in-s...

Exactly. Does anybody really sit and write a libraries solo these days? There's an omission of combined experience here. 2 others like yourself would be 18 years of experience.

(I understand the combined experience thing isn't perfect logic but that's not really my point.)

The thing those people are missing is 10,000 hours of deliberate practice. Showing up is not enough.

I'd rather work with someone who has five years of experience than someone with one year of experience repeated twenty times.

I read the grandparent as criticizing Java programmers. A sufficient number of bad programmers seem to fall in these trap often enough that the result is a mess.

Design pattern: I wouldn't be surprised if they are used too much.

Love towards getters/setters. Not the fault of the language, that's just bad practice. And no, you don't have encapsulation. Rarely, getters and setters do some verifications or filtering, but most of the time they don't, in which case you just have raw access to the object's mutable state. Be honest and make your variable public, that's less code. If you ever need to put checks or filters (almost never), then just refactor.

Long names: my jury is out for this one. In your example, I'd say the overly long name comes from an overly narrow functionality. For something that specific, you should use a description string.

Try/Catch: If your QA section tells you to check all exceptions, you may have quite a bit of those statements. (Also, maybe he included the body of the try/catch statements?)

Code that requires an advanced IDE to approach: a good IDE let you manage and tolerate higher levels of complexity. You'll also be less encouraged to simplify your code. You may not even notice when it becomes too complex for a humble vi user.

Verbose code: People tend to stop as soon as it works, without simplify their code further. It's not the language's fault, nor is it done on purpose. I hate when I see code like that. I often have to apply various correctness preserving transformations before I stand a chance at understanding it.