4 ms·

Java gets more hate than it deserves. "There are languages everyone complains about and languages nobody uses." Most of the hate comes from the overly complica

by api 1y ago

Java gets more hate than it deserves. "There are languages everyone complains about and languages nobody uses." Most of the hate comes from the overly complicated "enterprise design patterns" crap that took over the ecosystem in the late 90s into the 2000s, not the language itself. It's quite possible to write clean, clear, appropriately complex, well performing Java code. On the plus side, of all the languages I've used Java is one of the absolute best when it comes to long term maintainability of code. This is why it's used so heavily in large enterprises with long-lived business critical code bases. Being the "COBOL of the 1990s/2000s" is not an insult, and as a language it is far superior to COBOL in every way. It's not a bad language to program in at all, while COBOL will make you hate your life. It's also a safe language unless you break out of the JVM with JNI. It's the first safe language to get huge deployment if you don't count scripting languages. Safe doesn't mean you can't have security bugs of course, it just means you're not likely to have certain kinds of security bugs and stability problems like memory errors. The JVM is really a fantastic piece of engineering and IMHO represents a whole direction in computing I feel sad that we didn't take. We opted to stay close to the metal with all the security, portability, code reuse, and other headaches that entails, instead of going into managed execution environments that make all kinds of compatibility and reuse and portability problems mostly go away. The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible. The second biggest knock is that the JVM is still kind of a memory pig. CPU performance is great, sometimes converging with C or Rust performance depending on work load, but it still hogs RAM.

bheadmaster 1y ago
In my experience, the problem of Java is the lack of standardized tooling. To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try - and if not, debug the most-likely-XML spec file searching for invalid dependency that's printed out on the 1000-line error output... What Java is desperately missing is something like Python's `uv`. --- Sibling comment mentioned that debugging Java itself is also a nightmare, which reminds me of the many Spring Boot projects I've had to debug. Stack traces containing 90% of boilerplate code layers, and annotations throwing me from one corner of the codebase to another like a ragdoll... Admittedly, that's not inherently the problem of Java, but rather the problem of Spring. However, Spring is very likely to be found in enterprise projects.
- vips7L 1y ago
  I think this is really just anecdotal to your experience. Don’t you need to install a specific version of a compiler or interpreter for every language? Isn’t trying to build any complex project a pray on the first try? I’ve worked in Go codebases where it’s not simply “go build”. It’s: try go build, oops you need to use the make/justfile, oops don’t forget you need to install jq or some other random tool. Complex projects are complex.
  - bheadmaster 1y ago
    > Isn’t trying to build any complex project a pray on the first try? I managed to build Docker Daemon - one of the most widely used and complex Go projects - from source with a simple `go build`. I've never figured out how to build Jenkins from source. Do you know of any widely used Java project that has a simple build process? Maybe a positive anecdote could change my mind.
    - ohdeargodno 1y ago
      [dead]
  - Mawr 1y ago
    Not at all? There is an obvious difference between modern languages' (Go, Rust, Zig) build systems and the old mess (C++, Java, Python). You have one tool that does everything you need, from formatting and linting to package management and building. No need to choose between Maven or Gradle or try to string together five third party programs that barely work together. > I’ve worked in Go codebases where it’s not simply “go build”. A rather funny statement that says the opposite of what you intended. That you can expect most Go projects to be built with just `go build` is high praise.
    - vips7L 1y ago
      I expect most Java projects to be built with mvn package or gradle build. It doesn’t mean it’s always that simple. Simple projects can be built simply. Complex ones are never handled by 1 tool. There are plenty of examples in Rust and Go where people have to use make or just.
estimator7292 1y ago
I hate Java because debugging java code is worse than debugging assembly
- krior 1y ago
  As a Intellij-user I am more than a little confused. What are features missing from Java's debugging story?
  - eklavya 1y ago
    I have mostly heard these complaints from people who haven't used a java ide and/or do not know that jvms allow waiting for a debugger before starting execution (helps with all sorts of spring or whatever errors and boilerplate). That said, there is a shitload of "enterprise" fuckery in Java, but those Devs would have made a mess of any codebase anyway.
  - vips7L 1y ago
    Yeah this comment is wild to me. Java’s debugging is so good I can debug a remote server from my local machine.
    - Tostino 1y ago
      Something I've had to do a handful of times against production systems when we absolutely couldn't reproduce an issue locally. Such a great debug ecosystem.
- trollied 1y ago
  I hate to say it, but this is because you are not a Java developer. It’s very easy to debug.
- pjmlp 1y ago
  Found out another printf debugger.
- spreiti 1y ago
  How much experience do you have working in Java? This statement really surprises me because Java has some of the best in class tools to debug and troubleshoot issues.
hashmash 1y ago
> The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible. JNI was only ever designed to be good enough, and it is. The new FFM API aims to replace JNI in most cases, but it's designed to be "perfect". As a result, the new API took many years to develop, but JNI was quick to develop. It would be nice to have the FFM API much sooner, but alternatives like JNR and JNA have been around for a long time. There wasn't a rush to develop a JNI replacement.
ok123456 1y ago
The language has evolved a lot since the "enterprise" Java days. Much of the unnecessary ceremony was relaxed, and it became less religiously adherent to the idea that it was simply a compiled, statically typed successor to Smalltalk.
- DaiPlusPlus 1y ago
  ...but the elders still decree Java will never be granted ergonomics QoL improvements like getters/setters because...? At this point it feels like their pride is at stake.
  - stickfigure 1y ago
    I don't understand what you're saying. Java records don't need getters/setters. If you want that interface there's lombok.
    - ok123456 1y ago
      Records is a very new addition. lombok is writing bytecode directly to facilitate that.
  - peterashford 1y ago
    wut? Java has always had getters and setters
    - peterashford 1y ago
      Downvoted for stating an objective fact?
      - DaiPlusPlus 1y ago
        (I didn’t downvote you) In my post, I’m referring to Java’s refusal to adopt “properties” (i.e. methods invoked using the same syntax used for fields) like VB, C#, JavaScript, Swift, et cetera.
deleted 1y ago
[deleted]
pron 1y ago
> The biggest current knock against Java I see is JNI Then you'd be happy to learn that it's been superseded by FFM: https://openjdk.org/jeps/454 https://openjdk.org/jeps/454 (not in all situations, but in almost all). > The second biggest knock is that the JVM is still kind of a memory pig I would strongly recommend watching this keynote from this year's ISMM (International Symposium on Memory Management) on this very subject: https://www.youtube.com/watch?v=mLNFVNXbw7I https://www.youtube.com/watch?v=mLNFVNXbw7I The long and short of it is that (and I'm oversimplifying the talk, of course) if you use less than 1GB of RAM per CPU core, then you're likely trading off CPU for RAM in a way that's detrimental, i.e. you're wasting a valuable resource (CPU) to save a resource (RAM) that you can't put to good use (because the amount of work you can do on a machine is determined by the first of these resources to be exhausted, so you should use them in the ratio they're provided by the hardware). Refcounting collectors and even manual memory management (unless you're using arenas almost exclusively) optimise for memory footprint at the expense of CPU. Put another way, the JVM takes advantage of the more plentiful RAM to save on the more costly CPU.
- creata 1y ago
  Sorry if this is a stupid question, but does this argument continue to make sense for desktop applications, which don't typically use much CPU unless they're currently focused, but do use the same amount of RAM regardless of whether they're focused?
  - pron 1y ago
    When it comes to desktop apps much of the memory is paged out to disk anyway when a program is not focused.
- vladgur 1y ago
  When is FFM going to be production ready?
  - spreiti 1y ago
    Since JDK 22 https://openjdk.org/jeps/454 https://openjdk.org/jeps/454

by api 1y ago

bheadmaster 1y ago

In my experience, the problem of Java is the lack of standardized tooling. To build an average Java software, you have to install a specific version of JDK, download a specific build system (Ant, Maven, Gradle, Bazel), hope everything works out on the first try - and if not, debug the most-likely-XML spec file searching for invalid dependency that's printed out on the 1000-line error output... What Java is desperately missing is something like Python's `uv`. --- Sibling comment mentioned that debugging Java itself is also a nightmare, which reminds me of the many Spring Boot projects I've had to debug. Stack traces containing 90% of boilerplate code layers, and annotations throwing me from one corner of the codebase to another like a ragdoll... Admittedly, that's not inherently the problem of Java, but rather the problem of Spring. However, Spring is very likely to be found in enterprise projects.

vips7L 1y ago
I think this is really just anecdotal to your experience. Don’t you need to install a specific version of a compiler or interpreter for every language? Isn’t trying to build any complex project a pray on the first try? I’ve worked in Go codebases where it’s not simply “go build”. It’s: try go build, oops you need to use the make/justfile, oops don’t forget you need to install jq or some other random tool. Complex projects are complex.
- bheadmaster 1y ago
  > Isn’t trying to build any complex project a pray on the first try? I managed to build Docker Daemon - one of the most widely used and complex Go projects - from source with a simple `go build`. I've never figured out how to build Jenkins from source. Do you know of any widely used Java project that has a simple build process? Maybe a positive anecdote could change my mind.
  - ohdeargodno 1y ago
    [dead]
- Mawr 1y ago
  Not at all? There is an obvious difference between modern languages' (Go, Rust, Zig) build systems and the old mess (C++, Java, Python). You have one tool that does everything you need, from formatting and linting to package management and building. No need to choose between Maven or Gradle or try to string together five third party programs that barely work together. > I’ve worked in Go codebases where it’s not simply “go build”. A rather funny statement that says the opposite of what you intended. That you can expect most Go projects to be built with just `go build` is high praise.
  - vips7L 1y ago
    I expect most Java projects to be built with mvn package or gradle build. It doesn’t mean it’s always that simple. Simple projects can be built simply. Complex ones are never handled by 1 tool. There are plenty of examples in Rust and Go where people have to use make or just.

estimator7292 1y ago

I hate Java because debugging java code is worse than debugging assembly

krior 1y ago
As a Intellij-user I am more than a little confused. What are features missing from Java's debugging story?
- eklavya 1y ago
  I have mostly heard these complaints from people who haven't used a java ide and/or do not know that jvms allow waiting for a debugger before starting execution (helps with all sorts of spring or whatever errors and boilerplate). That said, there is a shitload of "enterprise" fuckery in Java, but those Devs would have made a mess of any codebase anyway.
- vips7L 1y ago
  Yeah this comment is wild to me. Java’s debugging is so good I can debug a remote server from my local machine.
  - Tostino 1y ago
    Something I've had to do a handful of times against production systems when we absolutely couldn't reproduce an issue locally. Such a great debug ecosystem.
trollied 1y ago
I hate to say it, but this is because you are not a Java developer. It’s very easy to debug.
pjmlp 1y ago
Found out another printf debugger.
spreiti 1y ago
How much experience do you have working in Java? This statement really surprises me because Java has some of the best in class tools to debug and troubleshoot issues.

hashmash 1y ago

> The biggest current knock against Java I see is JNI, which unlike the core language is absolutely horrible. JNI was only ever designed to be good enough, and it is. The new FFM API aims to replace JNI in most cases, but it's designed to be "perfect". As a result, the new API took many years to develop, but JNI was quick to develop. It would be nice to have the FFM API much sooner, but alternatives like JNR and JNA have been around for a long time. There wasn't a rush to develop a JNI replacement.

ok123456 1y ago

The language has evolved a lot since the "enterprise" Java days. Much of the unnecessary ceremony was relaxed, and it became less religiously adherent to the idea that it was simply a compiled, statically typed successor to Smalltalk.

DaiPlusPlus 1y ago
...but the elders still decree Java will never be granted ergonomics QoL improvements like getters/setters because...? At this point it feels like their pride is at stake.
- stickfigure 1y ago
  I don't understand what you're saying. Java records don't need getters/setters. If you want that interface there's lombok.
  - ok123456 1y ago
    Records is a very new addition. lombok is writing bytecode directly to facilitate that.
- peterashford 1y ago
  wut? Java has always had getters and setters
  - peterashford 1y ago
    Downvoted for stating an objective fact?
    - DaiPlusPlus 1y ago
      (I didn’t downvote you) In my post, I’m referring to Java’s refusal to adopt “properties” (i.e. methods invoked using the same syntax used for fields) like VB, C#, JavaScript, Swift, et cetera.

deleted 1y ago

[deleted]

pron 1y ago

> The biggest current knock against Java I see is JNI Then you'd be happy to learn that it's been superseded by FFM: https://openjdk.org/jeps/454 https://openjdk.org/jeps/454 (not in all situations, but in almost all). > The second biggest knock is that the JVM is still kind of a memory pig I would strongly recommend watching this keynote from this year's ISMM (International Symposium on Memory Management) on this very subject: https://www.youtube.com/watch?v=mLNFVNXbw7I https://www.youtube.com/watch?v=mLNFVNXbw7I The long and short of it is that (and I'm oversimplifying the talk, of course) if you use less than 1GB of RAM per CPU core, then you're likely trading off CPU for RAM in a way that's detrimental, i.e. you're wasting a valuable resource (CPU) to save a resource (RAM) that you can't put to good use (because the amount of work you can do on a machine is determined by the first of these resources to be exhausted, so you should use them in the ratio they're provided by the hardware). Refcounting collectors and even manual memory management (unless you're using arenas almost exclusively) optimise for memory footprint at the expense of CPU. Put another way, the JVM takes advantage of the more plentiful RAM to save on the more costly CPU.

creata 1y ago
Sorry if this is a stupid question, but does this argument continue to make sense for desktop applications, which don't typically use much CPU unless they're currently focused, but do use the same amount of RAM regardless of whether they're focused?
- pron 1y ago
  When it comes to desktop apps much of the memory is paged out to disk anyway when a program is not focused.
vladgur 1y ago
When is FFM going to be production ready?
- spreiti 1y ago
  Since JDK 22 https://openjdk.org/jeps/454 https://openjdk.org/jeps/454