Live data from Hacker News

Love It or Hate It, Java Continues to Evolve

azul.com

131–140 of 156 posts

Re: Love It or Hate It, Java Continues to Evolve

#131
post #91
post #58

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?

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

#132
post #17

In 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

I accept your pity. All my code has to be JRE5 compatible...

Re: Love It or Hate It, Java Continues to Evolve

#133

Earlier 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..

It's like playing Where's Waldo, to find the actual code in an enterprise Java/C# application.

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

#134

I'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…

And, of course, even G1 does not fill all memory before it starts collecting. Even generational GCs before G1 divide memory into smaller areas and try to collect garbage quickly to get rid of short lived objects, so we're speaking about Java 6 timeframe. Example from my real world server - most of objects are collected at young generation, so gc costs are minimal, very few objects get promoted to old generation and full GC runs are very sporadic (and they are sub 1sec).

Re: Love It or Hate It, Java Continues to Evolve

#135
I both love and hate it. I love the high quality libraries and ecosystem, reasonable performance, simple semantics. I hate the annotations and reflection magic, bloated frameworks, type erasure, lack of null safety, build systems. Luckily, it is possible to avoid some of that by not jumping on the bandwagon's standard stack. Leave that framework on the shelf, and Just Write Java. Unfortunately, many existing Java projects you come across in the wild are trainwrecks.

Re: Love It or Hate It, Java Continues to Evolve

#136
post #17

In 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 ?

I have not. The only major thing I see in Kotlin over Java right now (I don't do Android development) is data classes. Everything else is either in the language or should be soon which makes me hesitant to invest the time learning it.

Re: Love It or Hate It, Java Continues to Evolve

#137

I'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…

I don't think any of your description about how the JVM GC works is accurate. The default GC is generational so it generally does lots of garbage collection before it takes up the reaches the heap limit. I assume what you really want is for the Java heap to return memory to the OS. The default JVM GC isn't configured to do that but you can easily configure the JVM to do that.

> 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

#138
post #91

Earlier 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?

Perl and Ruby are at least as old but I never had to backslash everything when writing regexen in Perl or Ruby.

Re: Love It or Hate It, Java Continues to Evolve

#139
post #17

In 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…

Java already has both records/data classes[1] (including pattern matching) as well as value classes[2] in the works.

[1] https://cr.openjdk.java.net/~briangoetz/amber/datum.html

[2] https://openjdk.java.net/projects/valhalla/

Re: Love It or Hate It, Java Continues to Evolve

#140

I'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…

The JVM has state of the art GCs, name another platform that comes close in terms of offering the ability to tune it for throughput or latency as the JVM does, or that comes close in performance (.NET probably is the only contender).

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.

Post reply on HN