7 ms·

When I started my career in software development, SDE, and soon advanced to SRE, I hated Java. The extreme OOP paradigm made enterprise class situations impossi

When I started my career in software development, SDE, and soon advanced to SRE, I hated Java. The extreme OOP paradigm made enterprise class situations impossible to understand. But after a few short years, I began to appreciate it as a real, battle hardened ecology. Now, I consider it much better than modern trends such as Rust and Python. These kinds of niche optimizations are still significant. The OOP model allows them to be implemented with much less fanfare. This is in the context of billion-dollar platforms. With some basic performance testing and API replays, we're saving thousands of dollars a day. Nobody gets a pat on the back. Maybe some pizza on Friday.

jimmaswell 1y ago
I've seen Java described as made for companies to be able to rotate out mediocre programmers as efficiently as possible without letting them mess things up easily, and it makes a lot of sense from that perspective. Barebones semantics to the point of being Spartan (can't even define your own operator overloads), easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance).. Then there's C# which most anyone who's enthusiastic about software dev will find far nicer to work with, but it's probably harder for bargain basement offshore sweatshops to bang their head against.
- nradov 1y ago
  The lack of operator overloading is a bit annoying but in practice seldom a real problem. An operator is just a funny looking method. So what. There are worse fundamental problems in Java. For example the lack of a proper numeric tower. Or the need to rely on annotations to indicate something as basic as nullabilty.
  - saagarjha 1y ago
    It’s a massive annoyance when working with any sort of numeric code. Or custom collections. Or whatever else the standard library enjoys that nobody else gets to use.
- ivan_gammel 1y ago
  I remember the times on one of professional forums, where there was lots of questions about architecture in C# sections and almost none in Java section. Abundance of tools creates abundance of possibilities to get confused about what’s right. In Java many design decisions converged to some dominant design long time ago, so you no longer think about it and focus on business. It’s sometimes as bad as getter verbosity (thankfully record style is getting traction), but in most cases it’s just fine.
- atomicnumber3 1y ago
  I really don't think this stance aged well, even if it was closer to true way back when. IMO the spartan language is now Go, and Java has ended up the boring open source workhorse. The jvm is very performant compared to many stacks these days (python Ruby node) while still having a very compelling concurrent programming story, and has a lot of nice language feature things ever since 8 and onwards. Lambdas and streams are the big 8's, but I think virtual threads growing up and even new things like scoped variables are really compelling reasons to build a new thing in java right now.
  - knorker 1y ago
    > Java has ended up the boring open source workhorse. This statement surprised me. I can't even remember last time I ran any opensource Java.
    - dgoldstein0 1y ago
      Off the top of my head? Bazel is the Java program I use the most. Hadoop/hive and similar stuff also heavily Java but I'm not sure how much that's in use anymore
      - knorker 1y ago
        I'm not saying there's no Java in open source. And I'm aware of the projects you mention. I don't run them though. And they definitely don't qualify as "the boring open source workhorse". There are a couple of Java projects, and even one or two kind of successful ones. But Java in open source is very rare, not the boring workhorse. If I worked on a project that used Bazel, then sure, I'd use Bazel every day. But which is "the boring workhorse" of open source, if I gave you the option of Java, Make, Linux, gcc, llvm, .deb, would Java really be "the" one? Sure, maybe you could exclude most of those as not being "boring", like llvm. But "make" wins by any measure. And of course, it's almost by definition hard to think about the boring workhorse, because the nature of it is that you don't think about it. Checking now, the only reason I can find java even being installed on my dev machines is for Arduino IDE and my Android development environment. Pretty niche stuff, in the open source space.
- SkiFire13 1y ago
  > easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance) That sounds like a recipe for disaster though, as it generally makes code much harder to read.
  - dgoldstein0 1y ago
    Agree, inheritance tends to be overused when programmers try to get too clever. The flatter the class hierarchy the better
threeseed 1y ago
You can use the JVM without needing to use OOP e.g. Scala, Clojure, Python, Javascript, Ruby etc. Then you can get to benefit from Java's unparalleled ecosystem of enterprise hardened libraries, monitoring etc.
- neuroelectron 1y ago
  It's hot really your decision in a corporate environment.
SkiFire13 1y ago
Did you actually started to appreciate the same OOP that made class situations impossible to understand or did you gradually switched to a simplier OOP, made up of mostly interfaces and classes that implement them (as opposed to extending other classes)? In my experience OOP is actually pretty pleasant to work with if you avoid extending classes as much as possible. > These kinds of niche optimizations are still significant. The OOP model allows them to be implemented with much less fanfare. If you're referring to the optimization in the article posted then I would argue an OOP model is not needed for it, just having encapsulation is enough.
- Etheryte 1y ago
  I'm not sure if the argument that OOP is pleasant so long as you avoid any OOP is a very sturdy one.
  - _old_dude_ 1y ago
    OOP is great for libraries but leads to overly complex codes for applications. For a long time, Java was like, every classes is a library, i do not think it's a failure of OOP, it's a failure of Java. But I'm optimistic, I choose to see recent additions like records and pattern matching has a step in the right direction.
  - turtles3 1y ago
    I'd say that the 'poor man's closures' aspect of OOP - that is, being able to package some context along with behaviour is the most useful part for day to day code. Only occasionally is inheritance of anything other than an interface valuable. Whether or not this is an endorsement of OOP or a criticism is open to interpretation.
  - SkiFire13 1y ago
    OOP is the combination of encapsulation, abstraction, inheritance, and polymorphism. Ignoring inheritance does not mean avoiding OOP altogether.
    - 1y ago
davnicwil 1y ago
the mind blowing moment for me with Java came about 5 years into using it, when I encountered the idea - via some smart colleagues - that none of the extra 'stuff' is intrinsic to the language but rather is self-imposed. Turns out you can write java without the stuff. No getters and setters, no interfaces or dependency injection, no separate application server (just embed one in your jar). No inheritence. Indeed no OOP (just data classes and static methods). Just simple, c-like code with the amazing ecosystem of libraries and the incredibly fast marvel that is the JVM and (though this is less of a deal now with LLM autocomplete) a simple built in type system that makes the code practically write itself with autocomplete. It's truly an awesome dev experience if you just have the power / culture to ignore the forces pressuring you to use the 'stuff'.
- concerndc1tizen 1y ago
  I love Java in the same way. But that free-thinking definition of Java clashes with the mainstream beliefs in the Java ecosystem, and you'll get a lot opposition at workplaces. So I gave up on Java, not because of the language, but because of the people, and the forced culture around it.
  - wood_spirit 1y ago
    The over engineering creeps in anywhere there is collaboration. It’s not a Java thing, it’s a corporate thing. The new teammate who refactors the perfectly working sql pipeline; the teammate who makes story points a required field on your trouble ticket system, the teammate who just saw a conference talk on rust and wants to apply it etc. Most engineers are not zen masters seeking out simplicity; they are lost with poor grasp of desired business outcomes so they procrastinate by adding complexity and indirection and focusing on tech as if it were the destination not the journey.
    - 90s_dev 1y ago
      True, but there's also the bored engineers who just can't force themselves to write enterprise code unless they make it fun for themselves. I'm absolutely convinced this is why Clojure even exists and is so widely used in fintech.

jimmaswell 1y ago

I've seen Java described as made for companies to be able to rotate out mediocre programmers as efficiently as possible without letting them mess things up easily, and it makes a lot of sense from that perspective. Barebones semantics to the point of being Spartan (can't even define your own operator overloads), easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance).. Then there's C# which most anyone who's enthusiastic about software dev will find far nicer to work with, but it's probably harder for bargain basement offshore sweatshops to bang their head against.

nradov 1y ago
The lack of operator overloading is a bit annoying but in practice seldom a real problem. An operator is just a funny looking method. So what. There are worse fundamental problems in Java. For example the lack of a proper numeric tower. Or the need to rely on annotations to indicate something as basic as nullabilty.
- saagarjha 1y ago
  It’s a massive annoyance when working with any sort of numeric code. Or custom collections. Or whatever else the standard library enjoys that nobody else gets to use.
ivan_gammel 1y ago
I remember the times on one of professional forums, where there was lots of questions about architecture in C# sections and almost none in Java section. Abundance of tools creates abundance of possibilities to get confused about what’s right. In Java many design decisions converged to some dominant design long time ago, so you no longer think about it and focus on business. It’s sometimes as bad as getter verbosity (thankfully record style is getting traction), but in most cases it’s just fine.
atomicnumber3 1y ago
I really don't think this stance aged well, even if it was closer to true way back when. IMO the spartan language is now Go, and Java has ended up the boring open source workhorse. The jvm is very performant compared to many stacks these days (python Ruby node) while still having a very compelling concurrent programming story, and has a lot of nice language feature things ever since 8 and onwards. Lambdas and streams are the big 8's, but I think virtual threads growing up and even new things like scoped variables are really compelling reasons to build a new thing in java right now.
- knorker 1y ago
  > Java has ended up the boring open source workhorse. This statement surprised me. I can't even remember last time I ran any opensource Java.
  - dgoldstein0 1y ago
    Off the top of my head? Bazel is the Java program I use the most. Hadoop/hive and similar stuff also heavily Java but I'm not sure how much that's in use anymore
    - knorker 1y ago
      I'm not saying there's no Java in open source. And I'm aware of the projects you mention. I don't run them though. And they definitely don't qualify as "the boring open source workhorse". There are a couple of Java projects, and even one or two kind of successful ones. But Java in open source is very rare, not the boring workhorse. If I worked on a project that used Bazel, then sure, I'd use Bazel every day. But which is "the boring workhorse" of open source, if I gave you the option of Java, Make, Linux, gcc, llvm, .deb, would Java really be "the" one? Sure, maybe you could exclude most of those as not being "boring", like llvm. But "make" wins by any measure. And of course, it's almost by definition hard to think about the boring workhorse, because the nature of it is that you don't think about it. Checking now, the only reason I can find java even being installed on my dev machines is for Arduino IDE and my Android development environment. Pretty niche stuff, in the open source space.
SkiFire13 1y ago
> easy to take another class and copy it with small modifications but not mess it up for anyone else (inheritance) That sounds like a recipe for disaster though, as it generally makes code much harder to read.
- dgoldstein0 1y ago
  Agree, inheritance tends to be overused when programmers try to get too clever. The flatter the class hierarchy the better

threeseed 1y ago

You can use the JVM without needing to use OOP e.g. Scala, Clojure, Python, Javascript, Ruby etc. Then you can get to benefit from Java's unparalleled ecosystem of enterprise hardened libraries, monitoring etc.

neuroelectron 1y ago
It's hot really your decision in a corporate environment.

SkiFire13 1y ago

Did you actually started to appreciate the same OOP that made class situations impossible to understand or did you gradually switched to a simplier OOP, made up of mostly interfaces and classes that implement them (as opposed to extending other classes)? In my experience OOP is actually pretty pleasant to work with if you avoid extending classes as much as possible. > These kinds of niche optimizations are still significant. The OOP model allows them to be implemented with much less fanfare. If you're referring to the optimization in the article posted then I would argue an OOP model is not needed for it, just having encapsulation is enough.

Etheryte 1y ago
I'm not sure if the argument that OOP is pleasant so long as you avoid any OOP is a very sturdy one.
- _old_dude_ 1y ago
  OOP is great for libraries but leads to overly complex codes for applications. For a long time, Java was like, every classes is a library, i do not think it's a failure of OOP, it's a failure of Java. But I'm optimistic, I choose to see recent additions like records and pattern matching has a step in the right direction.
- turtles3 1y ago
  I'd say that the 'poor man's closures' aspect of OOP - that is, being able to package some context along with behaviour is the most useful part for day to day code. Only occasionally is inheritance of anything other than an interface valuable. Whether or not this is an endorsement of OOP or a criticism is open to interpretation.
- SkiFire13 1y ago
  OOP is the combination of encapsulation, abstraction, inheritance, and polymorphism. Ignoring inheritance does not mean avoiding OOP altogether.
  - 1y ago

davnicwil 1y ago

the mind blowing moment for me with Java came about 5 years into using it, when I encountered the idea - via some smart colleagues - that none of the extra 'stuff' is intrinsic to the language but rather is self-imposed. Turns out you can write java without the stuff. No getters and setters, no interfaces or dependency injection, no separate application server (just embed one in your jar). No inheritence. Indeed no OOP (just data classes and static methods). Just simple, c-like code with the amazing ecosystem of libraries and the incredibly fast marvel that is the JVM and (though this is less of a deal now with LLM autocomplete) a simple built in type system that makes the code practically write itself with autocomplete. It's truly an awesome dev experience if you just have the power / culture to ignore the forces pressuring you to use the 'stuff'.

concerndc1tizen 1y ago
I love Java in the same way. But that free-thinking definition of Java clashes with the mainstream beliefs in the Java ecosystem, and you'll get a lot opposition at workplaces. So I gave up on Java, not because of the language, but because of the people, and the forced culture around it.
- wood_spirit 1y ago
  The over engineering creeps in anywhere there is collaboration. It’s not a Java thing, it’s a corporate thing. The new teammate who refactors the perfectly working sql pipeline; the teammate who makes story points a required field on your trouble ticket system, the teammate who just saw a conference talk on rust and wants to apply it etc. Most engineers are not zen masters seeking out simplicity; they are lost with poor grasp of desired business outcomes so they procrastinate by adding complexity and indirection and focusing on tech as if it were the destination not the journey.
  - 90s_dev 1y ago
    True, but there's also the bored engineers who just can't force themselves to write enterprise code unless they make it fun for themselves. I'm absolutely convinced this is why Clojure even exists and is so widely used in fintech.