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

Java Virtual Threads Preview

openjdk.java.net

Post reply on HN
Print view View original

81–90 of 270 posts

Re: Java Virtual Threads Preview

#81

Post by BigRabbit »

shrewduser wrote: post #52
kjeetgill wrote: post #47

Earlier quoted context omitted.

>I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. I think you're mistaken. The Java community is just so tremendously larger relative to the Kotlin one, that this will have more users within months. I really liked what Kotlin was doing, but Java since got lambdas, they have closed the biggest gaps that drove migration.

Lambda's seem like one of the least interesting features of kotlin. There's so much more going on in the kotlin world than lambdas. it seems to me that kotlin is leading the way and java is following, but the delta between them is quite large and possibly growing.

The delta between Java and Kotlin is definitely decreasing.

What Kotliners used to say about Java back then:

- no data classes. Now there's records in Java. Check.

- no lightweight threads. Boom, project Loom came in.

- no support for FP. Now there are lambdas and :: operator in Java. Also, Stream API.

- no type inference. Then came 'var'.

And some minor things that are in Java now as well: pattern matching; sealed classes as a way to get ADTs in the foreseeable future; kind of immutable collections; etc.

Yeah, you can argue that these features are not-so-native and painful to use in Java comparing to other languages. And, as one who programs in Scala, I 100% agree with you here. But you can't argue that people used to switch to Kotlin and Scala without hesitation because it was worth it summing up all the switching pros and cons. Nowadays, this is not the case anymore. You don't have to risk and adopt a new language technology stack.

Delta is objectively decreasing. For sure.

Re: Java Virtual Threads Preview

#82

Post by jiggawatts »

polskibus wrote: post #46

Is this like .NET tasks? If so, what’s the async story here? Does it involve function colouring like in .NET?

The doco explains it quite well, so I won't repeat it here.

It's solving the same problem that async does, but it does it with virtual threads instead. The idea is that functions aren't coloured, and that normal threaded code will "just work".

I see some benefits of this approach, but I feel that what all of the solutions (Java, C#, Rust, etc...) are missing is structured concurrency[1], without which madness and eldritch horrors of late-night concurrent code debugging are guaranteed.

[1]: https://vorpus.org/blog/notes-on-structured-concurrency-or-g...

Re: Java Virtual Threads Preview

#83

Post by truth_seeker »

I am lost here. the non-goal mentioned here are actually worth taking as goals to be fulfilled so that every other language and library ecosystem which runs on JVM will get benefited.

Non-Goals:- It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. It is not a goal to automatically convert existing thread construction to virtual threads. It is not a goal to change the Java Memory Model. It is not a goal to add new inter-thread communication mechanisms. It is not a goal to offer a new data-parallelism construct in addition to parallel streams.

Re: Java Virtual Threads Preview

#84

Post by cryptonector »

philosopher1234 wrote: post #67
cryptonector wrote: post #64

There is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two en…

>On the whole, solutions on the CPS side of the spectrum are better, IMO. Just because you think they can be more efficient?

Not only that, but also because they make the programmer think about state representation.

Re: Java Virtual Threads Preview

#85

Post by Skinney »

foota wrote: post #54
pkulak wrote: post #13

Earlier quoted context omitted.

Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/Beam, it doesn't matter because you literally can't block a thread (while idle). This is the kind of thing that's not terribly useful until nearly every library you interact with is using it as well. Also, there's no new syntax, so you're stuck with all the sam…

If it's added to the VM then won't that allow languages like Kotlin to add support?

Yes, which is perhaps the best part about virtual threads. Java, Kotlin, Scala, Clojure, Gradle... everyone benefits.

Re: Java Virtual Threads Preview

#86

Post by Skinney »

vips7L wrote: post #72
foota wrote: post #54

Earlier quoted context omitted.

If it's added to the VM then won't that allow languages like Kotlin to add support?

Kotlin coroutines could take advantage of virtual threads but they still will have the syntatic problem of colored functions.

Kotlin can call regular Java APIs, though. Doesn't have to take the coroutine route.

Re: Java Virtual Threads Preview

#87

Post by Skinney »

vbezhenar wrote: post #26
hn_throwaway_99 wrote: post #9

Really excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual…

Java still eats like 5x ram compared to node, Java tools are slow, Java frameworks are gargantuan, even those claiming "lean". Java is fine if you don't care about RAM and start time, though.

Javalin is _very_ lightweight, and starts up fast. Use the framework that best suits your requirements.

Also, Java is working on reducing ram usage: https://openjdk.java.net/projects/lilliput/

Re: Java Virtual Threads Preview

#88

Post by Skinney »

daxfohl wrote: post #35

Awesome, now that we've just spent a year rewriting our backend with callback hell to make it async, we can spend the next year rolling it all back.

If it works, don't fix it.

Besides, this hasn't been targeted to a release yet, so it might not come before Java 19, which is a year from now. Even then, it will still be a preview, which likely means another year before it's a stable feature.

Re: Java Virtual Threads Preview

#89

Post by haimez »

lmm wrote: post #74
haimez wrote: post #51

Earlier quoted context omitted.

Arguably more visible because you have native JFR support for noticing such an event. Let’s remember, that Kotlin is a guest language and that the host platform implementations get host platform integrations natively.

In my experience plain old userspace code is always the easiest thing to debug, so a guest language (where a large chunk of the runtime itself will be, by definition, just plain old code) often ends up easier to understand.

In general, I would agree with you- because Kotlin or Java that corresponds to your own code should be easier to find and understand than hotspot’s C++ source code or the jit output.

Last I checked though, Kotlin was threading coroutine suspend/resume points into methods as part of bytecode generation (it’s been a while, please do let me know if I’m wrong on this) which is not something most engineers are ready to read in the simple case, much less when trying to interpret the compiler’s name mangling scheme.

In either case, the implementation that ships with the JVM will be more capable because of it’s privileged position of integrating with the runtime, so good news! Eventually Kotlin might be able to use the native facility.

Re: Java Virtual Threads Preview

#90

Post by pjmlp »

foota wrote: post #54
pkulak wrote: post #13

Earlier quoted context omitted.

Yes. But, since there are _two_ kinds of threads in Java (os and virtual), you still have to be very careful never to block a virtual thread. In Go/JavaScript/Beam, it doesn't matter because you literally can't block a thread (while idle). This is the kind of thing that's not terribly useful until nearly every library you interact with is using it as well. Also, there's no new syntax, so you're stuck with all the sam…

If it's added to the VM then won't that allow languages like Kotlin to add support?

Guest languages always have to deal with taking decisions that don't go along with the platforms, regardless how they boost being "better".
Post reply on HN