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

201–210 of 356 posts

Re: Java 20 / JDK 20: General Availability

#201

Post by kaba0 »

cryptonector wrote: post #197
kaba0 wrote: post #190

Earlier quoted context omitted.

M:N is not the interesting aspect of virtual threads at all, automagically turning blocking operations into non-blocking is - which has not really been tried before (with erlang and go being the first).

GNU Pth had "automagically turning blocking operations into non-blocking" ages ago, and it wasn't the first. I think what you probably had in mind is that C libraries of the 90s that did M:N threading didn't turn blocking operations into non-blocking? Using blocking operations to switch contexts is really nothing new. Heck, the cooperative multi-tasking systems of the 80s (Mac, Amiga) all essentially did that for pro…

> I think what you probably had in mind is that C libraries of the 90s that did M:N threading didn't turn blocking operations into non-blocking

Yes, mostly, though my history knowledge is definitely lacking so do correct me if I’m wrong.

But you are right, there was nothing fundamentally missing, probably just no good OS support for non-blocking IO calls in the early days? Though probably the IO-CPU ratio was also different, so the benefits were not as big?

Re: Java 20 / JDK 20: General Availability

#203

Post by 66fm472tjy7 »

paulmd wrote: post #135
taftster wrote: post #84

Earlier quoted context omitted.

I mean, that's OK though. Not sure why this is considered such a bad thing. You're missing out on some new language features, sure, but Java 8 is still reliable and rock solid. There's lots of companies that have hesitation or even inability to upgrade, hopefully there's at least some initiative and/or direction to do so. A company that is head-in-sand deliberately not upgrading from Java 8 is one thing. A company th…

There's very little reason not to upgrade from Java 8 at this point. Everything should be a drop-in replacement and there are significant performance benefits (garbage collection is leagues better) to doing so. The bigger problem is that a lot of places are stuck on Oracle JDK - 8u252 is the last free version so a lot of places just decided they'd never upgrade, nor do they want to look at whether Temurin or Coretto…

> Everything should be a drop-in replacement

This is not true for many applications. Due to the removal of many APIs from the JDK with Java 9, I needed the following dependency artifactIds to be able to move a JEE application with SOAP web services to Java 11: jaxb-api, jaxb-core, jaxb-runtime, istack-commons-runtime, jboss-jaxws-api_2.2_spec, glassfish-corba-omgapi, jboss-annotations-api_1.2_spec, activation, jboss-saaj-api_1.3_spec, saaj-impl, stax-ex, jsr181-api, txw2.

Many of these spec API/implementations are provided by different artifacts that are incompatible with each other. Some I only discovered when something failed at runtime as they perform implementation lookups and you don't get compile errors.

Additionally, many of the Maven plugins we used no longer worked and our application server failed to start.

Re: Java 20 / JDK 20: General Availability

#204

Post by soulbadguy »

acuozzo wrote: post #148
Longhanks wrote: post #114

Earlier quoted context omitted.

C++ has barely any feature complete compiler implementations and build systems aren’t ready for all of its additions, either (CMake and modules in particular). libstdc++ and libc++, gcc and clang are all not ready for production use or rather untested and/or buggy. Unless you’re targeting MSBuild Visual Studio Solutions and Windows only, C++17 is currently the most up to date, stable, and battle-proven version.

It's a shame "C with classes", as C++ originally was, didn't stick around for parallel development. I work with C daily and I'm well aware of its many shortcomings (e.g. its huge list of undefined behavior and its PDP11-centric view of modern architectures), but with some effort I believe it could function as a semi-portable second-level intermediate representation. Nim uses it as such, IIRC. Compiling to C first wou…

Rust ?

Re: Java 20 / JDK 20: General Availability

#205

Post by jillesvangurp »

philonoist wrote: post #87

Could the pundits of HN please compare this release with Kotlin?

Picking the release notes apart:

- ScopedValue (Incubator). Seems like a replacement for ThreadLocal that is intended to be a bit less dangerous (it is notorious for leaking memory and file handles). The Kotlin equivalent would be CoroutineScope. I'd say the latter is the cleaner solution. And probably ScopedValues came into existence for the same reason (co-routines & structured concurrency kind of breaking ThreadLocal a bit).

- Record Patterns (Second Preview). This looks a bit like Kotlin's smart casts. Useful. I think the Kotlin implementation with contracts is a bit more powerful and broadly applicable in more use cases. But nice of course.

- Pattern Matching for switch (Fourth Preview). That looks to me like an attempt to beef up the Java switch, which is a welcome change. The Kotlin equivalent would be when. Not a whole lot of difference at first glance. But combined with smart casts, Kotlin is quite nice already IMHO. Scala developers might disagree about a thing or two here..

- Foreign Function & Memory API (Second Preview). Looks like a nice JVM level feature for integrating native code that is potentially also of use to the Kotlin language developers.

- Virtual Threads (Second Preview). The second iteration of Loom. The JVM level implementation for this is going to make Kotlin's co-routines potentially even nicer. I don't think it should be that disruptive for Kotlin developers already using co-routines but performance increases are nice.

- Structured Concurrency. Also Loom related. From what I've seen of Loom so far, it should just work with your existing code without too much changes. And co-routines are definitely a nice API to do structured concurrency so not particularly relevant for Kotlin users. But it's going to be a big enabler for Java developers that have lacked this.

- Vector API (Fifth Incubator). Another JVM level optimization that the Kotlin developers should be able to make use of. I imagine projects like the kotlindl framework (a deep learning framework) can make use of this. A bit niche but nice if you use things like that.

So, nice incremental change and a few nice things that Kotlin will benefit from probably. Whether you use Java or Kotlin, it's going to be nicer for everyone once this ships in an LTS jdk.

Re: Java 20 / JDK 20: General Availability

#206

Post by vips7L »

munificent wrote: post #129
Alifatisk wrote: post #98

Earlier quoted context omitted.

What’ the hype with pattern matching? What does it solve?

If you've ever done any assembly programming or worked with other old or low level languages, you may have encountered an environment where you can write simple operator expressions, but you can't compose them. So this is OK: a = b + c d = e - f g = a * d But the compiler doesn't allow: g = (b + c) * (e - f) You have expressions that produce, but they don't compose. You can't produce a value from a more complex, nest…

> the "matching" part means that in many languages you can also ask questions about values as you destructure them,

I started implementing Lox with Java's sealed classes + pattern matching on switch. The exhaustiveness has been really nice to ensure I cover each new token/expression as I add them.

Re: Java 20 / JDK 20: General Availability

#207

Post by pshirshov »

ackfoobar wrote: post #109
pshirshov wrote: post #51

Earlier quoted context omitted.

Ideally like this: https://zio.dev/reference/#concurrency Or this: https://hoogle.haskell.org/?hoogle=fork

Other than STM, what is special? Almost everything there has an equivalent in traditional imperative programming.

More contracts enforced by the typer.

> Almost everything there

Everything. But the mere presence of "equivalents" doesn't make pure functional programming less valuable.

Re: Java 20 / JDK 20: General Availability

#208

Post by munificent »

garblegarble wrote: post #181
munificent wrote: post #136

Earlier quoted context omitted.

I work on Dart which is also adding pattern matching [1]. When we designed the syntax for guards, we also considered exactly these three choices before ultimately landing on "when" too. Our main reasoning was: "&&" is intuitive but it means that you can have a pattern that is immediately followed by an infix operator. That can be problematic if you ever want to make "&&" a valid pattern infix operator. And, in our ca…

Thank you, that's excellent insight into the thought process for the same feature at about the same time. You mention about the human-centred nature of syntax design... do you have any instinct for why one route vs another felt right to users? Do you feel like you've developed a better instinct for this over time, or is it still hard to predict what will feel natural to users?

> do you have any instinct for why one route vs another felt right to users?

That's a good question. It is something I spend a lot of time thinking about when I see how users react to a design. In this case, I don't think I have a good answer as to why "when" seemed to go down easier than "if".

> Do you feel like you've developed a better instinct for this over time, or is it still hard to predict what will feel natural to users?

I'd like to believe so, but "if" was my first pick, so I guess not. :)

I think what our team does have now that really helps is better processes to evaluate a design, talk about it, get feedback from users, and incorporate that feedback into the design. It's all pretty informal, but I think we're iteratively able to get designs users seem to like.

But it's always really hard. There are so many trade-offs and users have different preferences and expectations, so finding the right balance is always difficult. I think that's why it's so endlessly fascinating to me: you can never fully "solve" syntax design.

Re: Java 20 / JDK 20: General Availability

#209

Post by twblalock »

digitalsanctum wrote: post #144

As an engineer that last used Java when it was Java 11, I cringe at the thought of diving back in. A trade-off of increased release velocity for any language I suppose.

You don’t need to learn or use any of the new features. Most devs seem to still pretend they are writing for Java 8 anyway.

Re: Java 20 / JDK 20: General Availability

#210

Post by ackfoobar »

pshirshov wrote: post #207
ackfoobar wrote: post #109

Earlier quoted context omitted.

Other than STM, what is special? Almost everything there has an equivalent in traditional imperative programming.

More contracts enforced by the typer. > Almost everything there Everything. But the mere presence of "equivalents" doesn't make pure functional programming less valuable.

I have used cats-effect but not ZIO.

My view has been that reinventing imperative programming (IO monad) on math (pure FP) on imperative programming (the machine) brings me no benefit.

What does a coarse-grained effect type get you? The hard part of concurrent programming is concurrency, rather than knowing what code is effectful.

Post reply on HN