Java has become the language of "the noob." For a very large percentage of programmers, it's the first language that's presented to them. As such, there are endless examples of Java projects written by people who are still struggling with basic flow control, let alone project architecture. Some of these projects are written by smart people, and they're genuinely useful. As an example, think of the research biologist who's writing code for her thesis - code for which there's probably no measurable market.
Because it's the language of the noob, it's really easy to gain the kind of experience this author is describing. The kind where you just glide along, "turning the crank" not really learning anything for a long, long time. People come away honestly believing that because they've worked with the language for so long they're experts. That there's nothing left which will surprise them, or change the way they work in this language.
I've seen a lot of cases where these people bump up against some really cool things and never realize it. Because they don't understand it they quickly write it off as bad code/architecture/naming.
One of the most common examples I've seen of this is when people pull class names from the Spring application framework core, parading them around with no context and no knowledge of why they exist or why they might be incredibly useful, let alone why they sometimes make Java a joy to work with.
"AbstractSingletonProxyFactoryBean??! I don't care what it is, that's just stupid!" [1]
How ignorant.
> After all, you produced 576 classes that contain 10,000 lines of Java code, all of it seemingly essential, so you were doing your job.
I can agree that Java is a verbose language, and sometimes it's really difficult to express an abstraction succinctly as compared to some other languages. I can agree that it's also easy for people to run wild and over abstract. However, I think it's just as likely for people to mistake well abstracted code for needlessly verbose code.
> And nobody can glare at you and demand to know why you used 576 classes when you should have used 50...
Without a specific case, it's hard to figure out what's really going on here, but if this is a primary target metric, I'd say you're prioritizing the wrong things.
> ... because in Java doing it with only 50 classes is probably impossible.
Just throw separation of concerns out the window and you can write just about anything in one class.
1: http://docs.spring.io/spring/docs/2.5.x/api/org/springframew...