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

391–400 of 555 posts

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

#391

Post by seti0Cha »

kaba0 wrote: post #104
Cthulhu_ wrote: post #89

Earlier quoted context omitted.

Citation needed; first off, verbosity is not the problem, verbosity is NEVER the problem; any significant codebase will end up with millions of LOC (and tokens) regardless of language choice. Second, Java's infamous for having VeryLongClassNameFactoryBeans on the one hand, and deep class hierarchies on the other, with new classes being declared for everything. Third, it depends. You can set up a HTTP server in two or…

We were talking about PL features, and now you bring up a style of writing said language (which by the way comes from very different times and is no longer the norm)? Composition over inheritance has been a mantra in Java circles for a very long time now. The important difference is for example that Go can’t have proper error handling no matter how good the developer is, due to the language not having a proper abstra…

That's a feature not a bug. Go intentionally forgoes abstractions of that sort. I personally prefer well written Java exception handling, but often Java exception handling code is a bolted on afterthought. Go's approach is to make error handling something you have to think about for virtually every line of code, rather than a superstructure built around the code. This can feel slow and painful to write, but it guides the developer toward considering each error case individually, potentially resulting in more nuanced responses to errors. It also makes reading the code dead simple.

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

#392

Post by jayd16 »

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.

Does Java even have a MAUI equivalent? There are other open source frameworks for GUI apps. This feels like goal post shifting.

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

#393

Post by jayd16 »

andresp wrote: post #47
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.

C# GC, MS and external libraries, build, docs, tools support (especially for Linux) are all worse than Java.

MSBuild is actually really nice, haha. I wish Gradle was that simple.

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

#394

Post by [deleted] »

jayd16 wrote: post #356
kosolam wrote: post #304

The biggest win by far IMHO is a performant alternative for io intensive applications for async frameworks. Not using an async framework tremendously simplifies your code. Code complexity has an enormous projection on everything else, especially when talking on the business level. First and foremost the cost of development and time to market rises. And then comes the cost of maintenance.

If you want to run concurrent io requests, don't you still need to use an async framework and all the fork/join logic? I suppose the slow and naive way is now easier to let limp along as you won't run out of threads?

[deleted]

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

#395

Post by mike_hearn »

pdpi wrote: post #115
marginalia_nu wrote: post #66

Earlier quoted context omitted.

> How are Jars more portable than Go binaries when you need Java installed to run Jars? Uh, you don't...? https://docs.oracle.com/en/java/javase/14/docs/specs/man/jpa... > you don't need many libraries to begin with. This really depends on what you're doing. Having many libraries creates a lot of weird potential. You can absolutely subsist on less, but you can do more with more. A while back I found myself wanting to…

> Each format must be built on the platform it runs on, there is no cross-platform support. So now you're back to platform-specific packages, except you don't have Go's support for cross-compilation. Hardly much of an advantage.

You can make self-updating packages of JVM apps for Windows, macOS and Linux from your local OS ("cross compiled") using Conveyor:

https://conveyor.hydraulic.dev/

It's not JVM specific but it does understand how to bundle the JVM, use jlink to shrink it, read your classpath from Gradle etc.

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

#396

Post by mike_hearn »

kaba0 wrote: post #124
mike_hearn wrote: post #53

Earlier quoted context omitted.

Depends what the JARs do of course. Some desirable libraries are unfortunately slow. PicoCLI for argument parsing is one. It's got every feature you might ever want, but, it adds a couple hundred msec to startup. There is a HotSpot feature called AppCDS. It improves startup time by about 30% in my experiments. However you have to turn it on. Just running `java -jar` won't do it. Then there is GraalVM Native Image. It…

> PicoCLI for argument parsing is one Doesn’t it generate every additional code at compile time? I didn’t notice it slowing down my startup times, it’s mostly every other lib (which you usually have, as what’s the point of a hello world cli app)

I've timed it, it's very slow because it uses reflection to generate the model. The annotation processor doesn't let you avoid this step unfortunately. Native images do.

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

#397

Post by jve »

kaba0 wrote: post #369
jve wrote: post #311

Earlier quoted context omitted.

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... :(

Since OracleJDK is also just OpenJDK with a logo, I don’t believe that there is any software that runs on any recent OracleJDK but not on OpenJDK.

It may be windows specific thing like registry looking at specific runtime thing or whatever... This software doesn't run with OpenJDK: https://support.ismacontrolli.com/Software%20%26%20Tools/iSM...

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

#398

Post by alkonaut »

gpderetta wrote: post #266
alkonaut wrote: post #158

Earlier quoted context omitted.

The only example in the article does an explicit task though (in the form of a closure) e.g. something.submit(() -> { task code });

Don't be confused by the example, which semantically just shows a thread pool. It is hard to give an example in code as virtual threads ideally are purely an implementation detail and otherwise just look like normal threads. In a typical thread pool if you schedule more long running tasks than you have worker threads, you either have to queue your tasks waiting for a free worker or you have to spawn a new worker. If…

Oh so jvm virtual threads will suspend execution and yield without cooperation, just like an OS scheduler? That's a big difference to "just a task scheduler" which just queues tasks and distributes N tasks on M threads.

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

#399

Post by Kwpolska »

pjmlp wrote: post #296
Kwpolska wrote: post #236

Earlier quoted context omitted.

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.

Workarounds, and still doesn't fix the issues lacking from the company that owns .NET.

What does the company that owns Java offer? Their Java IDE is https://en.wikipedia.org/wiki/JDeveloper and nobody uses that. The latest release came out in 2019. Everyone is using IntelliJ IDEA or perhaps Eclipse.

What does the Python core community offer? IDLE is ugly, is barely an IDE, and didn’t have line numbers until a few years ago. Everyone is using PyCharm or VSCode.

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

#400

Post by foepys »

Kwpolska wrote: post #234
foepys wrote: post #59

Earlier quoted context omitted.

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

That's true. Single file deployments were also supported in .NET Framework, only a bit obscure by registering a callback for the assembly loader and explicitly bundling every dependency as a resource in the build process.
Post reply on HN