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

111–120 of 270 posts

Re: Java Virtual Threads Preview

#111

Post by Twisol »

halayli wrote: post #79

huh, they invented a new virtual vocabulary here and beat around the bushes to avoid saying coroutines. Sarcasm aside, it's probably to steer away from kotlin and make it easier for users when seeking help/docs online.

Coroutines are usually cooperatively scheduled (that's what the `co-` is for); these are pre-emptively scheduled, first by assignment to a pool of OS threads, and secondly by the OS' own thread scheduler. "Thread" is common nomenclature for pre-emptively scheduled tasks.

"Virtual" is a little less standard, but it draws on existing patterns: they've virtualized threads in the same way that the OS virtualizes the CPU (timeslicing) and virtualizes memory (literally, virtual memory).

Re: Java Virtual Threads Preview

#112

Post by moring »

A key point that I was particularly happy about is that ThreadLocals work well with virtual threads. My personal killer application: MDC for logging. I have just tried to build proper logging into a Javascript/Typescript application and none of the logging frameworks support MDC (or need cumbersome workarounds) because the async-isms in the underlying language prevent it from working as intended.

Re: Java Virtual Threads Preview

#113

Post by pkulak »

pjmlp wrote: post #93
vips7L wrote: post #91

Earlier quoted context omitted.

Yes but then your code isn’t idiomatic/multi platform/whatever. It’s a trade off (and one where I would always chose Java).

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?

Re: Java Virtual Threads Preview

#114

Post by elygre »

truth_seeker wrote: post #83

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…

Non-goals does not mean that they are bad goals, only that this particular project will not try to reach them. It’s a good way to manage expectations and scope creep.

Re: Java Virtual Threads Preview

#115

Post by EdwardDiego »

nogridbag wrote: post #70
sverhagen wrote: post #41

Earlier quoted context omitted.

If you use gargantuan Java frameworks, you'll use a lot of RAM. Just don't do that. With Spring Boot and similar frameworks, the RAM usage is really just very modest. I'll give you startup times, since I am not a believer in Quarkus and Graal. And I wouldn't use Java for a serverless function that needs to spin up and respond quickly. But for a typical (blue/green-deployed) application in my world, startup time is st…

Care to share more thoughts on Quarkus? I'm evaluating it for an upcoming app. From my limited reading it can be used with and without Graal.

My favourite bit of Quarkus is the same as my favourite bit of Micronaut - DI is compile time.

Re: Java Virtual Threads Preview

#116

Post by elygre »

jrh206 wrote: post #75

I really hope they change this `Thread.ofVirtual()` and `Thread.ofPlatform()` language; it sounds clunky and doesn't read like any Java that I've seen before.

https://blog.joda.org/2011/08/common-java-method-names.html?... has some background into the logic of static factory naming, covering from() and of().

Re: Java Virtual Threads Preview

#117

Post by Twisol »

sverhagen wrote: post #110
Twisol wrote: post #45

Earlier quoted context omitted.

I'd love to know who, of those pinned to an LTS release, has actually made use of a support contract with a company providing contracted support for an LTS release, whether it's Oracle or another company. I don't doubt they exist, but I have no idea what that support even looks like. My team has been happily tracking the twice-yearly JDK bumps. We started development three years ago against Java 8 and made a series o…

I am not on a support contract (rather the opposite: small team). But I am just being careful to get caught having to spend time upgrading code that I would otherwise not have touched, just because my non-LTS JVM runs out of support. Support is not just a support contract, but also security patches being released. In my understanding, for non-LTS versions that ceases quickly when the next version is out. Particularly…

Thanks for responding! For what it's worth, Ron Pressler (lead guy on the virtual threads work in the original article) has opinions on LTS:

https://old.reddit.com/r/programming/comments/lsuojl/jdk_16_...

pron> Assuming you've already made the last ever major upgrade past 8 (which was a relatively tough one), the reason people pay for LTS isn't because upgrades are overall cheaper -- they're costlier, actually -- but because they're willing to pay to not get new features. We've designed the LTS model mostly for legacy applications that don't see much maintenance, and want their dependencies, the JDK included, to change as little as possible.

https://www.reddit.com/r/java/comments/o0m6g8/the_state_of_p...

pron> People who want a new feature to land in LTS still misunderstand what LTS is. People who upgrade from LTS to LTS every three years also misunderstand LTS, and probably get the worst of both worlds.

Personally, I only found Java 9 to be anything like a stumbling block, and that's solely because the module system (Jigsaw) threw all the tooling for a loop. You can easily avoid Jigsaw and never worry about it.

The Java folks try really hard not to break backwards compatibility in general, and modules (+ JDK internals encapsulation) are the only major bugbears to worry about. If you can upgrade, I've found it extremely worthwhile.

> Particularly for non-LTS versions there may be experimental features that are not going to be compatible with subsequent versions, increasing my risk that a migration to the next version is occasionally not quickly.

As for this, the experimental features may as well not exist if you don't enable them. You absolutely should kick the tires with them if you can, but their presence is feature-flagged off by default. I'm on a small team myself, and it's been painless for us ever since jumping to 11.

Re: Java Virtual Threads Preview

#118

Post by dzonga »

Skinney wrote: post #87
vbezhenar wrote: post #26

Earlier quoted context omitted.

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/

there's Helidon: https://helidon.io/ as well from Oracle. though at the moment, I'm using Javalin.

Re: Java Virtual Threads Preview

#119

Post by Twisol »

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?

Eclipse and NetBeans do exist, and... ehhhhh. I used NetBeans for a long time; couldn't stand Eclipse; and these days I only use IntelliJ. But the others absolutely exist, and it'd be hard to say that Apache and the Eclipse Foundation aren't deeply embedded in the Java ecosystem.

Re: Java Virtual Threads Preview

#120

Post by kaba0 »

jiggawatts wrote: post #82
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 el…

https://openjdk.java.net/jeps/8277129
Post reply on HN