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

Java 20 / JDK 20: General Availability

mail.openjdk.org

Post reply on HN
Print view View original

351–356 of 356 posts

Re: Java 20 / JDK 20: General Availability

#351

Post by soulbadguy »

grumpyprole wrote: post #183
soulbadguy wrote: post #164

Earlier quoted context omitted.

At the risk of starting a flame war, the CLI and the coreCLR are fare superior VM and platform from a technical stand point. A lot of the features schedule for jave 21 / project Valhalla are just basically catching up to modern VM design. Of course there is more to the choice of a platform than just the technical differences.

The Java JVM was originally designed with a very dynamic language in mind, e.g. Java's support for dynamic loading, dynamic binding, reflection etc. The influences at the time were Smalltalk and ObjectiveC. As Java has evolved to be a much more statically typed language (especially Java 5), the JVM has somewhat struggled to exploit this while maintaining backwards compatibility. It's nowhere near as bad as the Python…

I agree with all of this. I am not sure if you meant this as a opposition to my comment.

Re: Java 20 / JDK 20: General Availability

#352

Post by hota_mazi »

still_grokking wrote: post #347
hota_mazi wrote: post #344

Earlier quoted context omitted.

Or you forming an opinion 30 years ago and never changing it. Textbook definition of "closed minded".

Those companies do the exact same thing (or even worse!) as 30 years ago. Of course nothing changed; besides the concrete wording of the PR and marketing materials. So there is no reason to change any opinions. Actually M$ got even more dangerous since than as they stopped to fight OSS and switched to their infamous and in this case even more concerning EEE strategy. But sure, I know some people get blinded by their…

If you think today's Microsoft is anything like the Microsoft of 20 years ago, you need to start reading up on tech news other than Slashdot.

Re: Java 20 / JDK 20: General Availability

#353

Post by ActorNightly »

kaba0 wrote: post #154
ActorNightly wrote: post #43

Earlier quoted context omitted.

Don't worry, someone will still manage put in a bug that results in a zero day in the next 2 years.

As opposed to what, powering off your servers so they can never get vulnerable?

As opposed to not using an enterprise, outdated language that is only used to essentially create jobs.

Re: Java 20 / JDK 20: General Availability

#354

Post by ActorNightly »

papercrane wrote: post #132
ActorNightly wrote: post #43

Earlier quoted context omitted.

Don't worry, someone will still manage put in a bug that results in a zero day in the next 2 years.

While the Java community has had some high profile vulnerabilities, I can't recall a major one that was actually tied to the JVM itself since dropped applets. Instead it's usually a popular library or framework.

Correct, but the reason those happen is because JDK, despite being on version 17 is still missing core features that are necessary for modern day use, like logging, backend web stuff, json parsing, e.t.c. So delegation to that is left to a large number of 3d party developers, and risk of pollution goes up, especially when you consider that there is financial incentive in the case of orgs like Apache to keep developing new features.

There should be no reason why someone deliberately writes code for a logging library to go fetch and execute code over the internet, and make that the default behavior. The fact that someone did that, and it got approved and published to production, should be an indicator for anyone competent to stay away from Java completely. There is plenty of other compiled languages out there for whatever use case you need.

Re: Java 20 / JDK 20: General Availability

#355

Post by grumpyprole »

soulbadguy wrote: post #351
grumpyprole wrote: post #183

Earlier quoted context omitted.

The Java JVM was originally designed with a very dynamic language in mind, e.g. Java's support for dynamic loading, dynamic binding, reflection etc. The influences at the time were Smalltalk and ObjectiveC. As Java has evolved to be a much more statically typed language (especially Java 5), the JVM has somewhat struggled to exploit this while maintaining backwards compatibility. It's nowhere near as bad as the Python…

I agree with all of this. I am not sure if you meant this as a opposition to my comment.

Not opposition, I was just trying to adding some historical context to your comment. I agree the JVM is poorly suited for modern Java and Oracle know this too, hence they are developing GraalVM.

Re: Java 20 / JDK 20: General Availability

#356

Post by DarkNova6 »

soulbadguy wrote: post #350
DarkNova6 wrote: post #247

Earlier quoted context omitted.

There would be a world for this argument if the CLR had anything even remotely resembeling hotspot runtime optimization. What you describe is the result of different philosophies/priorities. CLR focuses on static compile-time optimization, while the JVM is a highly dynamic construct with unmatched runtime analysis. In the 90s, there was a hope that with sufficient escape analysis, the need for user-defined primitives…

> What you describe is the result of different philosophies/priorities Maybe, it might also be the results of bad design decisions. > highly dynamic construct with unmatched runtime analysis As someone who spend quite a bit of time working on custom optimization around hotspot, i failed to see how anyone can describe the current state of the JVM ( J9 is a bit better) as unmatched. V8 and some some extend Julialang ha…

> Maybe, it might also be the results of bad design decisions.

Most assuredly not. Back in the 90s, the cost of loading memory and performing a CPU instruction was essentially equal. Today, fetching data from RAM takes 100x longer than a CPU instruction. This makes locality of data absolutely crucial and is a consequence of computing throughput increasing, but latency remaining stagnant (think of it like a database transaction).

With focus on garbage collection, it made sense to throw everything into the heap and use runtime analysis to inline as much as possible. Nobody has forseen how such hardware fundamentals would change over the next decades.

As far as I'm concerned, the proposed JVM spec for value types is the most promising model I have seen anywhere. Instead of a binary choice between entities in the heap and values on the stack, you have a more granular control with incremental benefits and constraints.

> As someone who spend quite a bit of time working on custom optimization around hotspot, i failed to see how anyone can describe the current state of the JVM ( J9 is a bit better) as unmatched. V8 and some some extend Julialang have much strong dynamic analysis.

Didn't know that, probably worth looking into. Though, I wonder how much you can compare V8 and the JVM, given the fundamental difference between a static and dynamic language.

> CLR focuses on static compile-time optimization

I thought that was common knowledge. I mean, does the latest CLR perform any significant amount of runtime optimizations? From what I've read the CLR makes sue of cpu-specific instructions such as SIMD, but no cache/layout optimizations or any inlining during runtime.

https://learn.microsoft.com/en-us/archive/blogs/davidnotario...

Post reply on HN