Comment by 2ion | Hacker News Reader

Comment by 2ion | Hacker News Reader

Parent Full thread

My main issue is that people writing Java (or for the JVM) because of their backgrounds (app-level code printers) almost completely disregard how that code works on the JVM, at scale, in a highly responsive and/or high throughput service. You can't just use a big, "safe bet" framework like spring, which taints EVERYTHING in that project, write a simple REST API and then do heavy work "in the background" without side effects.

"Running Java" requires detailed system engineering / ops expertise specific to how the JVM works and can be tuned, and all too often, how specific frameworks internally pile their abstractions on top of each other. Problem is, a modern "Java app" is a pile of large frameworks and libraries.

As a system engineer, I HATE Java applications written by clueless programmers. They are difficult to handle and I often have to dig in and fix bad usage of framework features that somehow passed code review by equally clueless "senior" developers. I then get to spend a day to find out why this or that connection pool in there managed by this or that library does not handle its connections correctly, just to find the magic framework level variable that tunes that specific screw. Stuff of nightmares.

Every Java project is also __severely__ underdocumented. That's because even if you write documentation for YOUR code, the framework has books of documentation on ITS specifics, and includes high-level libraries which THEMSELVES have heaps of specific documentation. Climbing the tree until one arrives at actual standard library calls is like climbing into clouds and hoping to see the sun some day.

IMO terrible Java code is partially due to how good the JVM is. Performance is within spitting distance of native code, so people can do TERRIBLE things and it won't tank performance.

Endless abstraction, loading giant things into RAM, looping over every item in huge arrays. Blocking server threads for minutes at a time. In most languages you would be punished severely with awful performance or OOM. Java chugs along until things get horrifically bad.

I think it’s not a language problem. Frontend devs can be just as clueless, and don’t even get started on bad programmers writing in low level languages. Basically, the reason Java become so popular at the time was the bad programmers writing leaking, segfaulting programs in c++. Now they write bad programs in Java that “works” when one looks at it from an angle and is lucky.

>"Running Java" requires detailed system engineering / ops expertise specific to how the JVM works and can be tuned

> almost completely disregard how that code works on the JVM

As an occasional clueless programmer, I've had occasion to touch systems written in Java. Could you point me at some resources?

What he wrote is not specific to Java. At scale, any program written in any language will require detailed knowledge. This includes "simple" languages like golang.

Reality is complex, and for non-trivial programs complexity is going to be somewhere.

> "Every Java project is also __severely__ underdocumented. That's because even if you write documentation for YOUR code, the framework has books of documentation on ITS specifics, and includes high-level libraries which THEMSELVES have heaps of specific documentation. Climbing the tree until one arrives at actual standard library calls is like climbing into clouds and hoping to see the sun some day."

This weaknes stems from Java being OO. On larger projects you start to have abstractions which tend to be insucfficiently documented or the documentation not being updated with changes. Throw in some helper classes here and there, from a certain point of complexity of the project from an outside perspective the whole thing looks like being obfuscated.

Reply on news.ycombinator.com