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

131–140 of 270 posts

Re: Java Virtual Threads Preview

#131

Post by pjmlp »

pkulak wrote: post #113
pjmlp wrote: post #93

Earlier quoted context omitted.

I learned an hard lesson in the Borland ecosystem. Always go with the platforms languages, and the IDEs from the platform owners, even if others are more shinny. Long term it always pays off to be the turtle, as the platforms move into directions not forseen by the shinny objects, and 3rd party IDEs keep playing catching up with SDK features.

What if the company that makes Kotlin is the one that makes the Java IDE?

They make one Java IDE, zero contributions to the JVM, and are all cozy with "screw you Java devs" Google godfather.

IBM does Java and the IDE (Eclipse).

Red-Hat and Microsoft do Java and the IDE (VSCode).

Re: Java Virtual Threads Preview

#132

Post by tadfisher »

pjmlp wrote: post #101
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.

Not only that, Kotlin has decided to marry Android as the platform language, so all JVM features not adopted by Google into ART means that Kotlin needs to decide to which master to obey, and with time Kotlin only path are to become its own platform. Hence why JetBrains is so eager with creating duplicates from every Java library in Kotlin.

JB is investing heavily into native, JS and wasm compiler backends, so there's a counterpoint. Another is that Kotlin is steadily adding support for features in newer Java runtimes, such as records. Another is that the Kotlin/JVM backend can target up to Java 17 bytecode, which is obviously not supported by Android.

This reads heavily of FUD.

Re: Java Virtual Threads Preview

#133

Post by pjmlp »

tadfisher wrote: post #132
pjmlp wrote: post #101

Earlier quoted context omitted.

Not only that, Kotlin has decided to marry Android as the platform language, so all JVM features not adopted by Google into ART means that Kotlin needs to decide to which master to obey, and with time Kotlin only path are to become its own platform. Hence why JetBrains is so eager with creating duplicates from every Java library in Kotlin.

JB is investing heavily into native, JS and wasm compiler backends, so there's a counterpoint. Another is that Kotlin is steadily adding support for features in newer Java runtimes, such as records. Another is that the Kotlin/JVM backend can target up to Java 17 bytecode, which is obviously not supported by Android. This reads heavily of FUD.

JB is trying to become Borland, with Kotlin as their Delphi while moving away from the JVM, turning Kotlin into a platform, lets see how high they fly, specially if Google's wind stops blowing.

Re: Java Virtual Threads Preview

#136

Post by kjeetgill »

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.

I'm not disagreeing with what you're saying here — at all. But what I am claiming is that when it comes to interest for and adoption of Kotlin within the JVM community that pull is smaller and shrinking. And that lambdas in Java are a big part of the reason for that.

Re: Java Virtual Threads Preview

#137

Post by ksec »

Is Virtual Threads part of Project Loom? i.e We expect Project Loom to land a little bit after this or are they completely separate issues and Project Loom is still far from landing?

Re: Java Virtual Threads Preview

#138

Post by jankotek »

fulafel wrote: post #130
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…

> 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 Linux can handle a ginormous amount of threads quite well, would be interesting to see a deeper investigation to this theory.

Java uses some memory for stack, about 1MB for each thread.

Re: Java Virtual Threads Preview

#139

Post by _0w8t »

bodhiandpysics1 wrote: post #124
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…

Maybe? it depends how you use them... any asynchronous operation will require memory, and that memory has to go somewhere. In CPS it goes on the heap... in the threaded style you have a stack you can put it on. This probably will waste some memory, though not as much as you might think. On the other hand, you can also reclaim the stack memory as soon as the operation finishes. The CPS technique creates garbage that a…

Green threads by definition cannot use OS stack and must allocate their stack memory on heap. Although this memory can be reused, as it is known from Go to avoid performance bottlenecks at least for Go code is better to allocate the stack as single continues block and copy the stack to a bigger block when thread’s stack reaches the current stack size. But then the whole stack space is pinned to the thread and cannot be reused.

For Java it may still be possible not to allocate the whole stack as a single chunk and instead have smaller chunks like one per few frames. But I really doubt that it can reduce memory pressure compared with CSP in real applications especially given how good GC became in Java.

Re: Java Virtual Threads Preview

#140

Post by captainmuon »

Twisol wrote: post #73
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…

I definitely prefer CPS, especially in functional languages (where the noise I complain about below often fades away entirely). On the other hand, CPS usually is a bit noisier from the developer's perspective; either your continuations are callbacks (whence callback hell) or your continuations are, as you say, manually compressed, tuned structures, which requires a fair amount of manual labor. I believe Rust uses a C…

What about async/await? You can basically write linear, imperative code, and don't have to deal with continuations or these "tuned structures" manually.

For me it is the cleanest style of writing concurrent code. And more and more I find I can also replace state machines with it, which makes sense because the compiler generates state machines under the hood usually.

You know, the kind of code where you have to communicate with some outside device and it is easy to do blockingly but devolves to state machine madness if you need to do other things concurrently. For example it would be really nice if I could use async/await in C on a microcontroller to read from a serial port...

Post reply on HN