Hacker News Reader

Comment by dnomad | Hacker News Reader

Except nobody actually writes Java code like this. Nobody implements the Map interface. It's just stupid code. The myth of Java bloat only serves people writing silly blog entries and others hung up on "best practices" from 15 years ago. It doesn't seem to have any practical basis.

View on HN

Sure they do. Every Java code base I've seen, including stuff written in the past year, using Java 8, with a mix of senior and junior developers (i.e., both those who cut their teeth on Java < 8, and those who learned > 8) was bloated. I'm thinking of one thing I'm dealing with now; 30 classes, 1800 lines (admittedly, using wc -l, so variable declarations and getters/setters are counted, but that is still visual space I had to skim through to figure out what it was doing. Oh, and that was -after- I removed some of the more obvious cruft), all of it proper OO...or I could have gotten it done in < 200 lines of Node in 1-3 files. All it does is accept a REST call, validate a bunch of parameters, check to see if the result is cached, if not, makes a request elsewhere and cache the result.

The myth of the myth of Java code only serves people defending Java academically, and those hung up on defending a language that enourages and defaults to bloat in any sort of shared coding environment. It doesn't seem to have any practical basis.

I've implemented the Map interface maybe a half a dozen times in my career in Java and many more in Clojure (using reify and friends). It's often very convient to offer a map interface to some remote service or data store as well as situations where I needed very custom caching or a specialized algorithm. The harder the thing I'm working on, the more motivated I am to present its API as something standardized if possible. This lets my users spend their complexity budget on what feature I'm offering and not on some random API I threw together.

Generally at least in Java or similar languages it's better to compose rather than implement or extend, i.e. HashMap works fine for most cases, and you may not really need to implement java.util.Map if you're building something "special" anyway. For frameworks and library authors, I can see more of an argument for it, I just generally have never subclassed collections except in certain cases such as building an LRU map which Java doesn't have.

There are places stuck with Java 6 or 7. Java 8 is still relatively recent for the Enterprise world.

Java 8 was a special version. Lambdas, stream API, diamond operator and new exception catching syntax together eliminated 50-80% of noise in Java code. The language is still verbose, but much less than pre-8.

(Still, I prefer reading Clojure. The form of Java language still causes too much structural noise in the codebase.)

> Java 8 is still relatively recent for the Enterprise world.

Most actual surveys put Java 8 penetration at 70 - 80%. Dig deeper and the <20% of projects not on Java 8 aren't under active development and are purely in maintenance mode.

This is what makes the entire exercise a myth. People may want to believe this stuff but again it has no practical basis.

Yep, like Java 1.4 running on Red-Hat Linux 5 deployments, where no one is allowed to touch beyond bug fixes and security updates.

I thought RHEL5 security updates were over right?

Yep, but I know of a few servers still running it.

How are those surveys done? I'm not sure if the type of companies I'm thinking about are answering surveys, or otherwise participate in broader developer community.

I was pretty much spearheading the use of Java 8 in one company ~2.5 years ago, but I know some teams actively developing there only upgraded a year ago, and I'm willing to bet the main customer still didn't...

Reply on news.ycombinator.com