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

Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

infoq.com

Post reply on HN
Print view View original

451–460 of 555 posts

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#451

Post by jjav »

jpgvm wrote: post #22
hintymad wrote: post #13

Earlier quoted context omitted.

My experience in small companies told me that younger generation didn’t choose Go because Go is objectively better than Java, but because they actively hate Java for it being out of fashion.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

> Irrational Fear of Java is one of the most confusing things among startup stage companies.

This so much. It's exhausting to experience startups shoooting themselves in the foot by not using Java where it's best simply because it's not hip.

Golden rule for startups, spend your innovation capital on your product not on trendy (unproven, immatue) implementation technologies. Use boring (aka mature, high performance, best tooling) technology.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#452

Post by nickstinemates »

wiseowise wrote: post #250
nickstinemates wrote: post #169

Earlier quoted context omitted.

`com.lol.myapp.factory.UserFactoryImpl.java` would like to have a word about its clear superiority

I can’t believe you’ve posted this seriously.

:)

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#453

Post by ithrow »

jpgvm wrote: post #278
black3r wrote: post #238

Earlier quoted context omitted.

Startup stage companies work on smaller codebases and primarily need to go as fast as possible from nothing to a working prototype without the need to use many advanced features.... Java is a good language, but the community around it, whether it's experienced developers or libraries are built for enterprises, who work on huge codebases and their primary concerns are security, performance, scaling, testing, all of wh…

In my experience the zero to something stage lasts way longer than people think and the cost of using immature and badly suited stacks like Typescript/etc bites way sooner than people think. They just keep pushing through it and telling themselves this is faster and everyone else is doing it so it can't be wrong. Case and point I built a new service recently in Kotlin on JVM. It's a SQL translation gateway that maps…

Most business applications today have a web UI, using nodejs/JS/TS simplifies things by having to deal only with one language and ecosystem. Most business apps today stick to only one database and maybe an additional nosql database. What you did is very unusual for most apps and is something only huge companies would do, like SAP or big banks.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#454

Post by jjav »

jve wrote: post #231
kaba0 wrote: post #170

Earlier quoted context omitted.

Do you have to buy a license for a regular Linux kernel? No. The exact same is true for OpenJDK. Just download any, for example one that is packages by your distro, or there is sdkman for developers to let you quickly choose from multiple vendors and any version.

Please help me understand. > To run your Java 8 application, a user needs the Java SE 8 Runtime Environment, which is available from Oracle under the Oracle Technology Network License Agreement for Oracle Java SE, which is free for personal use, development, testing, prototyping and some other important use cases covered in this FAQ https://www.oracle.com/java/technologies/javase/jre8-readme.... Straight from oracle.…

> Straight from oracle.com.

> How is this free?

Yes, don't go to oracle.com.

This is what you want (it's the same thing, but free open source): https://openjdk.org/

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#455

Post by jjav »

jve wrote: post #311
papercrane wrote: post #270

Earlier quoted context omitted.

If you want to use the Oracle runtime you need to pay Oracle. But the code itself is open source and you can instead use the Azul, Amazon, Red Hat, BellSoft, etc.. runtimes.

Finally got to the answer. So it IS paid from one particular vendor. I understand there are free options. But that makes it a mine in a field if you are not knowledgable enough. It went this deep into threading to really get an ack that there is a big red O' mine in there. And there is one piece that wont run without big red O... :(

> But that makes it a mine in a field if you are not knowledgable enough.

That seems like looking for a problem where one does not exist to be honest.

The peer comment regarding RedHat is spot on. Yes you can purchase a Linux distro from RedHat and pay lots of money.

That doesn't mean anyone will argue with a straight face that you can't run Linux for free!

It's the exact same scenario with Java. You could pay Oracle for a Oracle JDK if for some reason you reall want to, but approximately nobody does that.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#456

Post by bberrry »

whoisthemachine wrote: post #434

Using virtual threads only, can one make a non-blocking UI application? Or do you still need to fall back to Promises or callbacks?

I'm not positive about this but I believe the virtual threads can yield at syscalls (i.e. IO calls). I don't think GUI application code is littered with these syscalls where a virtual thread can naturally yield so you get non-blocking for "free". Someone please correct me if I'm mistaken.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#457

Post by cryptonector »

tsimionescu wrote: post #443
cryptonector wrote: post #406

Earlier quoted context omitted.

Yes, there's no silver bullet. Writing async code from the beginning is a much better approach to reducing memory footprint. But fibers/virtual threads/whatever-you-call-them will help scale many thread-per-client apps w/o having to pay for a rewrite as async code. That is worth a lot because the size of the thread-per-client Java codebases is enormous.

That is very much false. Async code is the wrong fit for Java, and it complicates everything tremendously. There also is no reason to believe async code should consume any less (or more, for that matter) memory than Loom-style concurrency. If anything, I would assume that, after a few rounds of optimization, Loom will be significantly better at managing memory than a Java async framework.

> Async code is the wrong fit for Java

Yes, async is a bad fit for Java. That's a problem with Java, not a problem with my statement.

> There also is no reason to believe async code should consume any less (or more, for that matter) memory than Loom-style concurrency.

I'm not familiar with Loom. I was referring to async vs. threaded. Async code does make the programmer make state explicit in objects rather than partially implicit as local variable values on the stack, and this is more compact than smearing part of the state on the stack.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#458

Post by jjav »

black3r wrote: post #238
jpgvm wrote: post #22

Earlier quoted context omitted.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

Startup stage companies work on smaller codebases and primarily need to go as fast as possible from nothing to a working prototype without the need to use many advanced features.... Java is a good language, but the community around it, whether it's experienced developers or libraries are built for enterprises, who work on huge codebases and their primary concerns are security, performance, scaling, testing, all of wh…

> security, performance, scaling, testing, all of which are secondary in most startup environments

I've done quite a few startups by now and I can say that in all of them the initial quick-n-dirty MVP codebase lasted well into the era where things like "security, performance, scaling, testing" became a priority.

Unless you are absolutely committed to throwing away the MVP (and I don't see how you could because as soon as sales team sees it they start selling it and you won't have time to throw it away), your best early move is to use technologies that will take you to the long haul because you will be stuck with that initial code for a very long time.

(This doesn't mean architecting the whole system for scale you won't hit in years, mind you. Just to use technologies that will make the transition to a mature engineering team easier. Such as Java, given the topic of this conversation.)

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#459

Post by jjav »

eptcyka wrote: post #277
jpgvm wrote: post #22

Earlier quoted context omitted.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

Irrational fear of Oracle is actually a perfectly valid factor in my opinion.

> Irrational fear of Oracle is actually a perfectly valid factor in my opinion.

Fear of Oracle is rational though, unlike fear of Java.

Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency

#460

Post by jjav »

tehbeard wrote: post #97
jpgvm wrote: post #22

Earlier quoted context omitted.

Irrational Fear of Java is one of the most confusing things among startup stage companies.

Java has the lingering shadow of Oracle hanging over it. That legalistic hydra is enough to make you second guess using it.

> Java has the lingering shadow of Oracle hanging over it.

This myth needs to be dispelled.

OpenJDK is Java, and is open source under GPL.

https://en.wikipedia.org/wiki/OpenJDK

https://github.com/openjdk/jdk/blob/master/LICENSE

Post reply on HN