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

231–240 of 555 posts

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

#231

Post by jve »

kaba0 wrote: post #170
jve wrote: post #145

Earlier quoted context omitted.

So if i have JDK (Which I must) I do have to buy those licenses.. for all our employees? > The Java Platform, Standard Edition (Java SE) and Java SE Universal Subscription from Oracle include the Java Development Kit (JDK), and Java Runtime Environment (JRE) https://www.oracle.com/java/technologies/faqs-jsp.html#:~:te... . Do I not need the Java SE subscription to use JRE? Do I not need the Java SE subscription to us…

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.com.

How is this free? Of course I don't need to pay for Linux kernel. Of course some products feature paid support. But how can I justify the quoted text that Oracle JRE is free?

I was going to say to the guy that decided there must be no Oracle Runtime at our company (some software doesn't work without it, I have no status if workaround has been found) - Hey, maybe Java SE is just the support/patches stuff and maybe we can use runtime? Until I stumble on that text - free for personal use, etc...

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

#232

Post by lenkite »

cutler wrote: post #201

`Executors.newVirtualThreadPerTaskExecutor()`. Java verbosity is alive and well.

So is Apple/Swift, but Apple always gets a smile instead of a smirk here on HN.

    func CMMetadataFormatDescriptionCreateWithMetadataFormatDescriptionAndMetadataSpecifications(
      allocator: CFAllocator?,
      sourceDescription: CMMetadataFormatDescription,
      metadataSpecifications: CFArray,
      formatDescriptionOut: UnsafeMutablePointer
    ) -> OSStatus

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

#234

Post by Kwpolska »

foepys wrote: post #59
pharmakom wrote: post #31

Earlier quoted context omitted.

C# already had all the advantages of Go (more or less) and more, yet Go is still growing. This has nothing to do with the technical capabilities of the languages.

To be fair, .NET only recently got AOT compilation and single binary (or self-contained) deployments as officially supported features.

If you target the classic .NET Framework on Windows, you could just ship a single folder for a long time The .NET Framework is shipped with Windows (though not necessarily at the latest version), and the deployment strategy for your average desktop/console app is just "copy the entire bin folder".

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

#235

Post by i386 »

afavour wrote: post #228
brabel wrote: post #207

Earlier quoted context omitted.

> I still frequently encounter situations which seem to only get resolved by throwing away my .m2 folder. I have my own issues with Maven, but never in my 16 years doing Java have I done that. What the heck leads you to believe doing that may fix something at all? .m2 is just a cache, it has pretty much zero impact on whether your stuff will build unless you had installed things there that are not available on a conf…

> m2 is just a cache, it has pretty much zero impact on whether your stuff will build Well… the cache can be broken. I’m not a Java dev so have no horse in this race but “it’s just a cache” doesn’t mean “it can’t ever be a problem”

Having worked with maven for about 15 years… it’s largely not a problem anymore. Unless you publish snapshots and depend on them.

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

#236

Post by Kwpolska »

pjmlp wrote: post #85
pharmakom wrote: post #65

Earlier quoted context omitted.

How so? Linux is a first class citizen in .NET these days.

A first class citzen would have support for MAUI, and something better than VSCode like macOS gets VS4Mac.

JetBrains Rider is available for Windows, Linux, and macOS, and it's much better than VS, VS for Mac, and VSCode.

It's not free, but VS isn't either for any serious commercial usage, and Rider is certainly worth the money.

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

#237

Post by afavour »

re-thc wrote: post #103
esafak wrote: post #44

Earlier quoted context omitted.

It's not. Java programmers I've seen don't use the latest idioms; they use pre-8.0 Enterprise Edition-ware because that's what they've been taught. It's a hideous sight and it has a lot of inertia. That's why I prefer kotlin.

What does this have to do with Java? As in there are no Javascript developers that use Promises instead of async/await? There's always legacy and people that live with it. It's a feature that there's no history now? And soon we're going to cry about Kotlin developers that don't use the latest idioms... oh give it a few years...

It’s all relative, though. One of the biggest complaints people have about the JS ecosystem is the lack of legacy: people do move from Promises to async quickly, when React switches to hooks everyone switches quickly, etc etc. For better or worse you can’t say the same about Java.

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

#238

Post by black3r »

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.

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 which are secondary in most startup environments and usually only start to matter years after the startup codebase is created...

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

#239

Post by lenkite »

Cthulhu_ wrote: post #102
Kwpolska wrote: post #32

Earlier quoted context omitted.

I would say that Go's error handling is a billion dollar mistake as well. The JVM is very impressive and a great thing to build upon. The Java standard library is vast and the developers actually care about it (unlike the Python folks, who gave up on having a sane HTTP client library built-in and instead defer to the third-party requests library). The Java language is not as great, lacking some quality-of-life featur…

> I would say that Go's error handling is a billion dollar mistake as well. I think you'll need to substantiate that one with some solid evidence. I don't see anything wrong with Go's error handling that cannot be explained by developer choice.

The Manning Book: "100 Go Mistakes and how to avoid them" gives solid examples of common gotchas with Go's error handling.

I have seen the below occur again and again in Go. (no compiler help, so this can only be caught in reviews and not if the reviewer is tired).

#50: Checking an error type inaccurately

#51: Checking an error value inaccurately

#54: Not handling defer errors

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

#240

Post by spuz »

kjto wrote: post #148
spuz wrote: post #130

Earlier quoted context omitted.

What is the virtual thread feature in .NET called? I can't find any information about it.

Tasks, simple intro here https://code-maze.com/csharp-tasks-vs-threads/

That looks similar to Java FutureTasks + Executors which is a very different concept from virtual threads.

Virtual threads mean that a blocking thread can yield to any other non blocking thread seamlessly and with very little overhead. .NET Tasks cannot do this as far as I can tell.

Post reply on HN