Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Java Turns 25 – Whats Next? [pdf]

oracle.com

Post reply on HN
Print view View original

171–180 of 286 posts

Re: Java Turns 25 – Whats Next? [pdf]

#171

Post by topspin »

throwaway189262 wrote: post #131
philipkglass wrote: post #118

Earlier quoted context omitted.

I'll shamefully admit that I have been running and writing JVM based services for years and I didn't know this. I thought that the fixed memory overhead for a simple JVM service was simply higher than with CPython as a fact of life. There are times when I'd happily trade more frequent GC pauses for a smaller per-process memory footprint. How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exc…

> How do you find a reasonably small Xmx that doesn't lead to OutOfMemoryError exceptions? That's tough to figure out. In new versions of Java, I think 14+, if you use ZGC collector it will return unused memory to the OS. Memory options vary depending on collector, but new versions of ZGC support "soft max" heap size and uncommit. Together it might be close to what you're looking for https://malloc.se/blog/zgc-softma…

> That's tough to figure out.

Indeed. That fact obviates this option in most cases. You have to spend time tweaking obscure, unstable knobs (the X in Xmx means Oracle is free to alter its meaning at any time) and risk either a.) serious failures in production or b.) poor results because the conservative choices necessary to avoid 'a' achieved little improvement and you wasted your time. The real world for most enterprises is a vast heard of communicating components and toying with GC switches multiplied by N things is a nonstarter.

So while you're technically correct that excessive memory use by conventional JVMs is "not always true," in practice you are wrong. That reality comes with a real cost that appears on a real bill every single month.

Re: Java Turns 25 – Whats Next? [pdf]

#172

Post by bryik »

bassman9000 wrote: post #108
hn_throwaway_99 wrote: post #87

Earlier quoted context omitted.

Ironically, while Java was the original "write once, run anywhere" language, it never succeeded in that regard (e.g. browser applets were never popular). Ironically, I believe Javascript has. I was pretty much exclusively a Java programmer for the first decade and a half of my career, before moving to Node and TypeScript. I don't think I could ever go back at the point. Most importantly, this is my first time where t…

Is there any major player or project doing backends in JS?

Uber: https://eng.uber.com/uber-tech-stack-part-two/

Re: Java Turns 25 – Whats Next? [pdf]

#173

Post by zmmmmm »

dunefox wrote: post #13
Irishsteve wrote: post #3

Top point talks about targeting data scientists. It would be interesting seeing what that means in their mind. Based on the current state of affairs oracle and the jvm seem very far away from mainstream ML

Nobody in their right mind would choose Java for anything ML-related.

Seems a bit of an overstatement - there are huge production systems doing massive ML using Spark, Hadoop, Kafka etc. In some areas these are the defacto solutions. They can't all be "not in their right mind".

Re: Java Turns 25 – Whats Next? [pdf]

#175

Post by zmmmmm »

throwaway189262 wrote: post #114
topspin wrote: post #69

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud bills. There are alternative JVMs and other tools, some of which is embryonic at this point, but what the world wants and what Java really needs to continue thriving is efficient memory use by the bog standard JVMs that work with everything.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

Not sure that is all of it. You can try turning down the max total memory to eg: 64mb and see what you can still run. An awful lot of stuff just can't, while similar applications in conceptually higher level languages (eg: Python, PHP, etc) happily execute.

The various factors I see are:

    - JVM overhead 10-15mb seems to be required just to get off the ground,
      which directly relates to the JVM replicating a bunch of OS 
      functionality (inevitable tradeoff for portability)
    - Missing value types - any complex data structure ends up with 
      big overhead from storing references
    - Stack frames - if you need a lot of threads you need a lot of stack,
      and a surprising number of threads run
Some of this will get addressed in upcoming releases, will be interesting to see how it goes.

Re: Java Turns 25 – Whats Next? [pdf]

#176

Post by zmmmmm »

deepakarora3 wrote: post #148
throwaway189262 wrote: post #114

Earlier quoted context omitted.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

All OK except when you need the same level of performance for those 0.001% of requests when the GC kicks in and takes the response time outside acceptable limits. Due to this reason alone, my company is planning to move off a popular Java based API gateway and to a C++ envoy side car implemented service mesh. And I am wondering if this is really worth it.

They should definitely investigate the new low-latency gc options in the JVM.

Re: Java Turns 25 – Whats Next? [pdf]

#177

Post by non-entity »

wk_end wrote: post #139
StreamBright wrote: post #80

Earlier quoted context omitted.

Java is still my default language after so many years (even though through Clojure). I think Java's biggest advantage is the JVM though, if it had an ML programming language on the top without null and proper interfacing to Java packages I would never look at anything else. Just like .NET has F#.

What's your opinion of Scala?

No the commenter you're replying to, but I've actually looked into Scala a few times and while it has some big criticisms I don't necessarily disagree with, there we're many things I actually liked about the language. I briefly considered picking up for a side project, but ultimately went with something else that provided more relevant features and abstractions.

Sadly, in the real world, it seems that Scala is mostly relegated to the Spark world.

Re: Java Turns 25 – Whats Next? [pdf]

#178

Post by titzer »

throwaway189262 wrote: post #114
topspin wrote: post #69

One thing that is hurting Java today is memory usage. Conventional JVMs use a lot of memory relative to essentially everything else and this is drives up cloud bills. There are alternative JVMs and other tools, some of which is embryonic at this point, but what the world wants and what Java really needs to continue thriving is efficient memory use by the bog standard JVMs that work with everything.

That's not always true. Most of the time when Java uses a ton of memory it's because people use the default memory settings. If you tell Java to use up to 90% of system RAM, it will. Garbage collection is expensive so it will delay until memory is depleted. This is a different GC design than V8 and Go, which use older collector designs with high overhead. They need to collect very frequently because their stop the wo…

> This is a different GC design than V8 and Go, which use older collector designs with high overhead.

I think this information is a bit dated. Go has a highly advanced concurrent collector with very low pause times (~1-100μs). V8 also has incremental marking, concurrent marking, and parallel compaction. Its pause times are more like 100-1000μs. V8's GC has been tuned more and more to save memory (i.e. smaller heaps) because people have so many tabs open these days.

Re: Java Turns 25 – Whats Next? [pdf]

#179

Post by sk5t »

pabl0rg wrote: post #165
rzwitserloot wrote: post #34

Earlier quoted context omitted.

> A lot must have happened since then. Yes. As others have said, 'java is stable' which means the old stuff still works. Which in turn means that a lot of people are still using it and still writing blog posts about it. That still makes these old things often obsolete, or needlessly complex and just 'lesser than'. They don't support certain nice features or support them very badly, or have other significant downsides…

Baeldung has decently up-to-date tutorials. Try kotlin instead of Java, and if you must use java, read the book Effective Java. If you use kotlin, check out ktorm for db access, http4k for http api’s

Baeldung's content is IMO uniformly quite deficient. If you want examples of how to do things poorly, which examples may or may not compile, or if there's no other alternative, then I guess read the Baeldung article.

Try Scala instead of Kotlin, it's much more powerful, and you can safely avoid the mad Scala libraries jam-packed with symbol infix notation.

Re: Java Turns 25 – Whats Next? [pdf]

#180

Post by apta »

vips7L wrote: post #76
apta wrote: post #73

Earlier quoted context omitted.

With project Valhalla (value types), as well as the GC improvements in recent JDK releases (e.g. they are much more aggressive in releasing unused heap back to the OS), this should be a much smaller issue going forward. On another note, I'm not aware of other freely available GCs in other languages that are able to easily scale to multi-GB/TB scale memory usage. A while ago, I benchmarked an open source key/value gol…

> e.g. they are much more aggressive in releasing unused heap back to the OS By aggressive you mean they actual do that now right? As far as I know before ZGC no gc did that and they're still back porting that feature to G1 right? Edit: I'm actually quite pleased with ZGC I have the eclipse language server use it and my editors memory usage on average is so much lower.

I believe it has been backported to JDK14 (and JDK15 was released this past week). Also Shenandoah should be production ready in JDK15, so you might want to give it a shot.
Post reply on HN