One thing I would really love to see is a better way how you manipulate strings. Variable interpolation would be nice and you wouldn't have to have all that ugly string concatenation all over the place.
Don't forget regular expressions. How anyone puts up with having to escape all backlashes is beyond me. But, then, I'm used to Perl and Ruby. Scala, Clojure and Kotlin don't have this problem so why is the Emperor Without Clothes That Is Java having such a hard time?
Love It or Hate It, Java Continues to Evolve
131–140 of 156 posts
Re: Love It or Hate It, Java Continues to Evolve
#132In my experience most people don't like Java due to experiences they had before Java 8. This means they were used to the bloat, config as XML style world which made Java a pain to write and slow to run. Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. Then you throw in frameworks like javalin or sparkjava and suddenly they are not as hostile a…
I may work with java soon, so I was reading about Spring and it was yet again a dive into insane amount of verbose over engineering that I ran away from years ago. It's true that post 8 Java becomes palatable. And someone on reddit just showed me this piece of stats: https://www.jetbrains.com/lp/devecosystem-2019/java/ 83% on java 8, java 11 nicely going up I pity those forced to work with old techniques
Re: Love It or Hate It, Java Continues to Evolve
#133Earlier quoted context omitted.
I'd say there is no upside for the complex invisible magic. Half the time you have to run the application and pray that the configuration beans you've placed are working and if not, you are pretty much in trouble. Perhaps you missed a step in adding a configuration decorator in your application or configuration class, or used some deprecated method or used some incorrect class in the class hierarchy for the bean you…
it's not even magic, it's redundant over engineering at its peak haskell has magic, but at least its concise..
I think it's a fundamentally different mentality as far as the code. The codebase is so obfuscated that it might as well be binary data rather than plaintext files. You need an IDE to manipulate it efficiently.
Re: Love It or Hate It, Java Continues to Evolve
#134I'd like to see a JVM with a garbage collector that isn't designed to always consume the maximum amount of memory before it starts collecting. If you configure the JVM to have at most 400MB and it's current heap size is 120MB and you allocate 0.5MB every second or simply allocate 400MB of temporary objects that could be collected right away, it will allocate more GC heap until it hits the maximum 400MB and only then…
Re: Love It or Hate It, Java Continues to Evolve
#135Re: Love It or Hate It, Java Continues to Evolve
#136In my experience most people don't like Java due to experiences they had before Java 8. This means they were used to the bloat, config as XML style world which made Java a pain to write and slow to run. Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. Then you throw in frameworks like javalin or sparkjava and suddenly they are not as hostile a…
did you ever try Kotlin ? whats your opinion there ?
Re: Love It or Hate It, Java Continues to Evolve
#137I'd like to see a JVM with a garbage collector that isn't designed to always consume the maximum amount of memory before it starts collecting. If you configure the JVM to have at most 400MB and it's current heap size is 120MB and you allocate 0.5MB every second or simply allocate 400MB of temporary objects that could be collected right away, it will allocate more GC heap until it hits the maximum 400MB and only then…
> JVM is such a failure
I'm genuinely confused why you would consider that to be the case. Especially since your preferred alternative (WebASM) is just about as bad or worse by your stated measures (start up time, GC).
Re: Love It or Hate It, Java Continues to Evolve
#138Earlier quoted context omitted.
Don't forget regular expressions. How anyone puts up with having to escape all backlashes is beyond me. But, then, I'm used to Perl and Ruby. Scala, Clojure and Kotlin don't have this problem so why is the Emperor Without Clothes That Is Java having such a hard time?
Because it's 20+ years old and tries to be as source compatible as possible?
Re: Love It or Hate It, Java Continues to Evolve
#139In my experience most people don't like Java due to experiences they had before Java 8. This means they were used to the bloat, config as XML style world which made Java a pain to write and slow to run. Once I show them Java 11 with var keyword, lambda's and streams they start appreciating how modern the language has become. Then you throw in frameworks like javalin or sparkjava and suddenly they are not as hostile a…
Agreed on all points. You mentioned Go, so I'd like to add that Project Loom is the OpenJDK initiative to add green threads/coroutines to the JVM which I'd love. The tricky thing with "data classes" are that everyone wants something similar but different between the various terms: records, data classes, value types. Personally, what I want from this is essentially Lombock-style all-args constructors, equals, hashcode…
[1] https://cr.openjdk.java.net/~briangoetz/amber/datum.html
Re: Love It or Hate It, Java Continues to Evolve
#140I'd like to see a JVM with a garbage collector that isn't designed to always consume the maximum amount of memory before it starts collecting. If you configure the JVM to have at most 400MB and it's current heap size is 120MB and you allocate 0.5MB every second or simply allocate 400MB of temporary objects that could be collected right away, it will allocate more GC heap until it hits the maximum 400MB and only then…
If you don't want memory usage to go up to 400MB, then you can set the maximum memory the JVM can use to less than 400MB. It only makes sense from an efficiency and throughput standpoint to use as much memory available for performance.
JVMs regularly run on GBs or even TBs of heap space in production.
Both Shenandoah and ZGC target lower pause times (at the expense of throughput, naturally). There are commercial offerings like offerings from Azul that target low pause times as well.
> the JVM is probably the worst part about the Java ecosystem
On the contrary, the amount of optimizations that the JVM performs, as well as the monitoring, management, hotswapping, etc capabilities are second to none.
> It's slow
The fact that the JVM tops several charts here says otherwise: https://www.techempower.com/benchmarks/#section=data-r17&hw=...
> (mostly startup performance)
This is already being resolved through GraalVM. See for example https://quarkus.io/
> because the JVM is such a failure.
It only runs the backends of companies like Amazon, Google, FB, EA, LinkedIn, Ebay, Apple, Netflix, and countless others. Not to mention it's being used in high performance spaces like HFT.