7 ms·

What is the argument in favor of server-side Java in 2021? It seems like alternatives like Go, Python, or even JS are far ahead at this point

the_af 6y ago
Far ahead in what sense? In my previous job we used Java and the benefits were a huge ecosystem of libs and tools, plenty of monitoring tools, a ton of expertise and people who understood its memory model and quirks and were able to troubleshoot production problems. The JVM is rock solid and has great performance for backend with lots of transactions. I'm not experienced with Go, Python doesn't seem particularly suitable, and server-side javascript looks like a nightmare to me. NodeJS seems crippled to me.
- paulryanrogers 6y ago
  One benefit I've been seeing with server side JS is from FAAS like Lamba which can serve unpredictable loads very inexpensively.
  - eeperson 6y ago
    How is that a benefit specific to JS? Don't those platforms generally support Java as well?
    - cle 6y ago
      They do but the Java ecosystem takes a hit here, with many libraries being slow to initialize. The slower it takes to startup, the longer it takes to absorb the new load, to the point where you either keep some headroom (IOW, waste $$$), or try to predict load (complex, also wastes $$$). There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time, but there are so many downsides and pitfalls right now with Graal that I don't consider it a serious solution to the problem. It's basically creating a new ecosystem, which means one primary motivation--to take advantage of the Java ecosystem--is much less compelling. This isn't constrained to the public ecosystem, lots of companies have their own internal libraries, and Java makes it very easy and even encourages doing lots of expensive things at startup, like classpath scanning and pre-caching things. For a long time, Java made explicit decisions to de-prioritize startup time to improve maintainability (reflection/scanning/dynamic classloading) and runtime performance (e.g JIT). This tradeoff doesn't work out so well in a world of ephemeral processes that come and go as demand changes. I guess what's specific to JS, Go, Python, et al is the cultural emphasis on fast startup. Interestingly these all come from different constraints but the net result is that, in general, you can go from cold to serving traffic much faster than with Java, with a lot less effort.
      - eeperson 6y ago
        > There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time, but there are so many downsides and pitfalls right now with Graal that I don't consider it a serious solution to the problem. It's basically creating a new ecosystem, which means one primary motivation--to take advantage of the Java ecosystem--is much less compelling. I'm not sure I understand what the downsides are for Graal and FAAS. There are some pitfalls around reflection but even those don't seem to hard to avoid. Is that what you are referring to?
        alserio 6y ago
        Not gp but avoiding the reflection pitfalls is not so straightforward at all, you have to chase what your dependencies are doing to satisfy the "closed world" hypothesis. I still like java more than javascript, but writing performant serverless functions using js is way more easy right now
        eeperson 6y ago
        You don't have to chase your dependencies. You just need an adequate suite of tests and then run them with the Graal Tracing Agent enabled [1]. [1] - https://medium.com/graalvm/introducing-the-tracing-agent-simplifying-graalvm-native-image-configuration-c3b56c486271 https://medium.com/graalvm/introducing-the-tracing-agent-sim...
        cle 6y ago
        Your tests would need to exercise all your transitive dependencies' code paths that are used in production. I very rarely see tests written that way.
        cle 6y ago
        Graal has incomplete support for Java. Last time I tried a few months ago, ObjectOutputStream was not supported (I think it is now?), which was a critical part of a library I was using, forcing me to abandon Graal. Dealing with reflection is pretty awful, you have to comb through your entire dependency graph. Targeting the compiler for a different OS/architecture than the host is difficult, to say the least. There are so many great languages and runtimes to pick from these days...I can't imagine why anyone would willingly choose a technology like that. (Don't get me wrong, Graal is a fascinating technology, and I hope that one day it is able to seamlessly compile Java code to native executables...but it's not there yet.)
- AaronFriel 6y ago
  The JVM is rock solid, and recent improvements in garbage collection have reduced tail latencies dramatically. But I find that most people who say that it has "great performance" have not built a parallel implementation in JS, Go, Rust, or even .NET Core. I'm omitting memory unsafe languages by default and Python here, because I think that's the domain Java competes in, and Python lacks the investment these other languages have in performance. The lack of value types and the amount of pointer chasing that JVM languages do as a result, the way generics are implemented via type erasure (which the JIT then has to re-optimize), and so on usually mean that CPU and memory usage for the same throughput is much higher than a competing implementation in a different language. And on older JVMs, tail latency will be orders - plural - of magnitude worse. It is absolutely true though that for most workloads that efficiency isn't necessary and the ability to reuse that ecosystem reduces time and cost to develop. But it's just definitely not true that Java has "great performance" and I don't think that's ever really been true.
  - ssijak 6y ago
    TechEmpower Web Framework Benchmarks would like to disagree with you.
    - AaronFriel 6y ago
      I don't think those are particularly realistic workloads, as they don't involve substantial amounts of working with in-memory data. Which of the TechEmpower benchmarks uses an ORM? Before I finished drafting my comment I did have a sentence like this, which I removed, "Barring obscene amounts of optimization", so yes, some web servers like netty and jetty have gotten to a level of good performance in terms of handling plain requests. But most line of business backends are not using plain jetty/netty, they aren't just responding to every request with the same "SELECT" query to a backend database. They're doing computation, they're storing intermediate data in data classes like ArrayList, TreeMap, etc. And then of course due to business requirements, they often have to implement some in-process caching, and suddenly the lightweight Java application is a bloated multi-gigabyte CPU consuming monster. I just don't see that happening often with more memory and cache friendly languages like Go, Rust, Swift, or even JavaScript on V8/Node.js.
buster 6y ago
A huge developer base and eco system? What specifically, can't be achieved in Java, that you think node is needed for?
- Scarbutt 6y ago
  Rendering Javascript.
  - SahAssar 6y ago
    There is https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) and https://en.wikipedia.org/wiki/GraalVM https://en.wikipedia.org/wiki/GraalVM. The latter of those is the second fastest js server runtime (es4x) according to techempower benchmarks: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zik0sf-f https://www.techempower.com/benchmarks/#section=data-r20&hw=... I haven't tried any of those, but saying the JVM can't run JS is not true.
    - Scarbutt 6y ago
      GraalVM is not a drop-in replacement for the JVM and Rhino is slow as molasses compared to V8.
      - vips7L 6y ago
        > GraalVM is not a drop-in replacement for the JVM As far as I understand, yes it is. GraalVM is just HotSpot with the graal jit compiler instead of C2.
rjsw 6y ago
Java has support for the schema definitions that I need, the other languages you list don't. I am happily using JPA/Hibernate too.
ssijak 6y ago
What is the best argument against it? And the whole JVM platform in general (Kotlin, Scala, Clojure...)
- AzzieElbab 6y ago
  I can’t speak for others, but scala’s has two of the best sql db libs I ever used, namely doobie and quill. https://github.com/getquill/quill https://github.com/getquill/quill https://tpolecat.github.io/doobie/ https://tpolecat.github.io/doobie/
rakoo 6y ago
It works ? I'll argue that 90% of problems solved by SaaS today could be solved by any of the usual suspects of languages. What matters more is the architecture you choose. Choice of language is mostly a convenience choice, based on how comfortable you will be editing software in that language (that includes not only your proficiency, but also the availability of libraries and frameworks to help you)
deleted 6y ago
[deleted]

the_af 6y ago

Far ahead in what sense? In my previous job we used Java and the benefits were a huge ecosystem of libs and tools, plenty of monitoring tools, a ton of expertise and people who understood its memory model and quirks and were able to troubleshoot production problems. The JVM is rock solid and has great performance for backend with lots of transactions. I'm not experienced with Go, Python doesn't seem particularly suitable, and server-side javascript looks like a nightmare to me. NodeJS seems crippled to me.

paulryanrogers 6y ago
One benefit I've been seeing with server side JS is from FAAS like Lamba which can serve unpredictable loads very inexpensively.
- eeperson 6y ago
  How is that a benefit specific to JS? Don't those platforms generally support Java as well?
  - cle 6y ago
    They do but the Java ecosystem takes a hit here, with many libraries being slow to initialize. The slower it takes to startup, the longer it takes to absorb the new load, to the point where you either keep some headroom (IOW, waste $$$), or try to predict load (complex, also wastes $$$). There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time, but there are so many downsides and pitfalls right now with Graal that I don't consider it a serious solution to the problem. It's basically creating a new ecosystem, which means one primary motivation--to take advantage of the Java ecosystem--is much less compelling. This isn't constrained to the public ecosystem, lots of companies have their own internal libraries, and Java makes it very easy and even encourages doing lots of expensive things at startup, like classpath scanning and pre-caching things. For a long time, Java made explicit decisions to de-prioritize startup time to improve maintainability (reflection/scanning/dynamic classloading) and runtime performance (e.g JIT). This tradeoff doesn't work out so well in a world of ephemeral processes that come and go as demand changes. I guess what's specific to JS, Go, Python, et al is the cultural emphasis on fast startup. Interestingly these all come from different constraints but the net result is that, in general, you can go from cold to serving traffic much faster than with Java, with a lot less effort.
    - eeperson 6y ago
      > There are attempts to fix this with e.g. Graal, which effectively does the expensive initialization and reflection at compile time, but there are so many downsides and pitfalls right now with Graal that I don't consider it a serious solution to the problem. It's basically creating a new ecosystem, which means one primary motivation--to take advantage of the Java ecosystem--is much less compelling. I'm not sure I understand what the downsides are for Graal and FAAS. There are some pitfalls around reflection but even those don't seem to hard to avoid. Is that what you are referring to?
      - alserio 6y ago
        Not gp but avoiding the reflection pitfalls is not so straightforward at all, you have to chase what your dependencies are doing to satisfy the "closed world" hypothesis. I still like java more than javascript, but writing performant serverless functions using js is way more easy right now
        eeperson 6y ago
        You don't have to chase your dependencies. You just need an adequate suite of tests and then run them with the Graal Tracing Agent enabled [1]. [1] - https://medium.com/graalvm/introducing-the-tracing-agent-simplifying-graalvm-native-image-configuration-c3b56c486271 https://medium.com/graalvm/introducing-the-tracing-agent-sim...
        cle 6y ago
        Your tests would need to exercise all your transitive dependencies' code paths that are used in production. I very rarely see tests written that way.
      - cle 6y ago
        Graal has incomplete support for Java. Last time I tried a few months ago, ObjectOutputStream was not supported (I think it is now?), which was a critical part of a library I was using, forcing me to abandon Graal. Dealing with reflection is pretty awful, you have to comb through your entire dependency graph. Targeting the compiler for a different OS/architecture than the host is difficult, to say the least. There are so many great languages and runtimes to pick from these days...I can't imagine why anyone would willingly choose a technology like that. (Don't get me wrong, Graal is a fascinating technology, and I hope that one day it is able to seamlessly compile Java code to native executables...but it's not there yet.)
AaronFriel 6y ago
The JVM is rock solid, and recent improvements in garbage collection have reduced tail latencies dramatically. But I find that most people who say that it has "great performance" have not built a parallel implementation in JS, Go, Rust, or even .NET Core. I'm omitting memory unsafe languages by default and Python here, because I think that's the domain Java competes in, and Python lacks the investment these other languages have in performance. The lack of value types and the amount of pointer chasing that JVM languages do as a result, the way generics are implemented via type erasure (which the JIT then has to re-optimize), and so on usually mean that CPU and memory usage for the same throughput is much higher than a competing implementation in a different language. And on older JVMs, tail latency will be orders - plural - of magnitude worse. It is absolutely true though that for most workloads that efficiency isn't necessary and the ability to reuse that ecosystem reduces time and cost to develop. But it's just definitely not true that Java has "great performance" and I don't think that's ever really been true.
- ssijak 6y ago
  TechEmpower Web Framework Benchmarks would like to disagree with you.
  - AaronFriel 6y ago
    I don't think those are particularly realistic workloads, as they don't involve substantial amounts of working with in-memory data. Which of the TechEmpower benchmarks uses an ORM? Before I finished drafting my comment I did have a sentence like this, which I removed, "Barring obscene amounts of optimization", so yes, some web servers like netty and jetty have gotten to a level of good performance in terms of handling plain requests. But most line of business backends are not using plain jetty/netty, they aren't just responding to every request with the same "SELECT" query to a backend database. They're doing computation, they're storing intermediate data in data classes like ArrayList, TreeMap, etc. And then of course due to business requirements, they often have to implement some in-process caching, and suddenly the lightweight Java application is a bloated multi-gigabyte CPU consuming monster. I just don't see that happening often with more memory and cache friendly languages like Go, Rust, Swift, or even JavaScript on V8/Node.js.

buster 6y ago

A huge developer base and eco system? What specifically, can't be achieved in Java, that you think node is needed for?

Scarbutt 6y ago
Rendering Javascript.
- SahAssar 6y ago
  There is https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) https://en.wikipedia.org/wiki/Rhino_(JavaScript_engine) and https://en.wikipedia.org/wiki/GraalVM https://en.wikipedia.org/wiki/GraalVM. The latter of those is the second fastest js server runtime (es4x) according to techempower benchmarks: https://www.techempower.com/benchmarks/#section=data-r20&hw=ph&test=db&l=zik0sf-f https://www.techempower.com/benchmarks/#section=data-r20&hw=... I haven't tried any of those, but saying the JVM can't run JS is not true.
  - Scarbutt 6y ago
    GraalVM is not a drop-in replacement for the JVM and Rhino is slow as molasses compared to V8.
    - vips7L 6y ago
      > GraalVM is not a drop-in replacement for the JVM As far as I understand, yes it is. GraalVM is just HotSpot with the graal jit compiler instead of C2.

rjsw 6y ago

Java has support for the schema definitions that I need, the other languages you list don't. I am happily using JPA/Hibernate too.

ssijak 6y ago

What is the best argument against it? And the whole JVM platform in general (Kotlin, Scala, Clojure...)

AzzieElbab 6y ago
I can’t speak for others, but scala’s has two of the best sql db libs I ever used, namely doobie and quill. https://github.com/getquill/quill https://github.com/getquill/quill https://tpolecat.github.io/doobie/ https://tpolecat.github.io/doobie/

rakoo 6y ago

It works ? I'll argue that 90% of problems solved by SaaS today could be solved by any of the usual suspects of languages. What matters more is the architecture you choose. Choice of language is mostly a convenience choice, based on how comfortable you will be editing software in that language (that includes not only your proficiency, but also the availability of libraries and frameworks to help you)

deleted 6y ago

[deleted]