Java is a theocracy. A small subset of the things that the designers considered to be 'good design' are syntactically enforced, even when doing so provides no reward other than purity, and other equally important design guidelines are not enforced; as a result, programmers are stuck with particular mostly-aesthetic restrictions, regardless of whether or not they are actually appropriate. (A good example of this is the one-class-per-file rule, which has only recently been lifted. The tendency for large java codebases to contain thousands of files, each of which do almost nothing, is because of this.)
On the other hand, and contributing to the problem, is the primary community of Java programmers -- people who learned Java in school, were taught by people who were trained initially in imperative languages, and learned only the subset of concepts and features designated in some accreditation specification (if you learned Java in high school in the united states, you absorbed the contents of the AP Computer Science curriculum, which teaches encapsulation and big-O notation but doesn't touch upon any elements of good design that are not enforced by the compiler). The language designers didn't seem to have too much of a problem, in some cases, catering to this large class of new programmers who didn't really understand OO -- after all, the only reason Java is so big in industry is that it's taught in schools. So, despite enforcing a shallow conception of OO, most Java code is basically imperative code -- and huge structures (like ORM systems) and widespread features (beans) have been written specifically so that people can think about their code imperatively while adhering to the letter of the law.
As a result, Java is a patchwork of extremely strict requirements, many of which were not well thought-through. Important features present in every other interpreted language and most compiled languages were not implemented at all, or were put off for twenty years. Multiple inheritance was dropped entirely because they figured that they'd need to implement a collision resolution system as complicated as the one in C++ (even though they could have done a simple one instead and gained most of the benefits), and as a result, relatively simple projects require inheritance trees that are more complicated than C++'s collision resolution system could ever be, and re-factoring jobs that would be trivial with multiple inheritance of any kind instead require complete rewrites. Generics were put off for twenty years, despite being a VM feature, leading to hundreds or thousands of lines added to many projects for handling the equivalent of casting to a void pointer and casting back.
The bottom line is that Java has whims, and it enforces its whims by fiat. As a result, programmers write thousands of extra lines of code. These whims are not clearly driven by pragmatism or by idealism, and since most Java programmers aren't truly familiar with a language other than Java, they haven't internalized that language design decisions are not mysterious proclamations handed down from heaven but instead choices made by harried programmers working against a deadline.