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

261–270 of 555 posts

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

#261

Post by wiseowise »

Dinux wrote: post #75
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

Are you kidding me? If it wasn't for large enterprise corporations Java would be long dead by now. Ever since Oracle took over Java has seen almost no improvements. The logical comparison is Java to C#, and C# has seen _a lot_ of improvement over the last 7 years or so. It just so happens that Java is sometimes unavoidable for Android development were Kotlin is not (yet) possible. Java is, like its large corporate us…

Are you trolling?

https://openjdk.org/jeps/0

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

#262

Post by JackFr »

iforgotpassword wrote: post #81
jve wrote: post #56

Earlier quoted context omitted.

Can you compile so that JRE is bundled with the program? I'm a C# developer and I also have a kind of resistance of java - having to install JRE and now the minefield Oracle made with the JRE, I'm hoping not only that I don't have to code in it, but that I don't have to use ANY Java program just to avoid the runtime or have to choose between different versions of it. And then the .jar files and how you execute them i…

I think you can with 3rd party tools, as with Python, but why would you? If your app is literally a single executable with no additional resources, maybe it makes sense, but otherwise, just bundle the JVM like jetbrains does. And as you mostly use Java on the backend, you're probably running Linux where a free and open jre is packaged, so just target that and not worry about it ever.

> And as you mostly use Java on the backend, you're probably

running in a container.

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

#264

Post by can3p »

kaba0 wrote: post #94
impulser_ wrote: post #58

Earlier quoted context omitted.

I started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so p…

> Go is very simple language that is just as powerful as Java I don’t think so, Go is very low on expressivity. Generics help, but I don’t see anything like JOOQ for go, just as an example. Also, no real alternative to Java’s stream api, which can at times make code much more readable than the 4 nested for loops with 4 different exits.

https://github.com/volatiletech/sqlboiler

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

#265

Post by aembleton »

pizza234 wrote: post #30
TheDong wrote: post #10

So with this, the last thing Go had going for it over Java is gone, right? Java has an obviously better type system, while Java originated the billion dollar mistake, Java also at this point has much better practices around handling nulls than Go, Java's jars are more portable than go's binaries, Java's GC performs better, Java has a more mature ecosystem and more libraries... Java has better IDE support and comparab…

What's the modern startup time of JARs? I haven't used Java in a long time, but long ago, the relatively slow startup time was a dealbraker for using java to write small tools.

Just tested on an M1 Macbook Pro and it took 148ms

I have a tool I created that creates a git branch based off a Jira ticket number. If I don't supply a ticket number then it errors out straight away, so I think most of that 148ms is the JVM starting up.

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

#266

Post by gpderetta »

alkonaut wrote: post #158
killerstorm wrote: post #150

Earlier quoted context omitted.

I guess the idea is that you don't have to write tasks explicitly - if you have a sequence of actions you can just write it as a regular code, and the runtime will automatically insert points where your code might be suspended waiting for IO or other threads.

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 your tasks are CPU bound and you do not care about latency/fairness, queuing is what you want. If your tasks might do blocking operations, you might underuse your CPU, or you simply want more fairness and not simple FIFO execution; in this case you can spawn new threads but OS threads are costly to spawn and schedule beyond a certain number. Virtual threads are simply cheaper threads as the scheduling is done in userspace and the JVM can in theory be smart about it.

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

#267

Post by re-thc »

surfsvammel wrote: post #64
impulser_ wrote: post #58

Earlier quoted context omitted.

I started with Java and I will most likely never go back. I mainly use Go now. People want to learn/write Go. It's hard to find anyone that wants to learn/write Java. People probably prefer Kotlin over Java today. It's a much better language and you can keep using JVM libraries. Go is very simple language that is just as powerful as Java, if not more powerful due to not having to rely on the JVM. That's why it's so p…

It’s not hard to find people who want to write Java. I do it all the time. We have been hiring and writing Java code for fifteen years and have not seen a decline in the interest.

Sorry, it's hard to find you. I had to scroll down this page.

It's even harder to find Rust developers and yet it's well liked - so? So?

The funny part is most of the anti-Java logic is flawed. Maybe using Java will fix that for them :p

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

#268

Post by the_gipsy »

wiseowise wrote: post #260
the_gipsy wrote: post #111

Earlier quoted context omitted.

It's simply that the average Java project is out of date and not worth updating, which says a lot.

As in works just fine and generates business value despite not being touched in years? Yes, says a lot.

As in the effort to update or just change anything major is similar to a rewrite.

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

#269

Post by wiseowise »

pritambarhate wrote: post #181
wiseowise wrote: post #167

Earlier quoted context omitted.

It’s hard to find quality people who want to write Java.

Really? So you mean to say there are no quality people in the millions of Java programmers out there?

No quality people - no, small amount - yes. And millions of Java devs are not your pool.

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

#270

Post by papercrane »

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

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.
Post reply on HN