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

331–340 of 555 posts

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

#331

Post by datadeft »

DrScientist wrote: post #163
datadeft wrote: post #45

Earlier quoted context omitted.

There are legitimate reasons to chose Go over Java, starting with the build system and the amount of effort needed to produce a single binary. I use Java for 20 years and Go for ~2. I am not actively hating Java but I value my time, specially that was wasted on maven + co.

Maven isn't Java. I've used java for over 20 years and managed to almost completely avoid it. As with npm - I think automatic dependency management at the library level pulls in far too much of the world - most of which your code doesn't actually depend on because the one function you need in lib A, doesn't actually require lib B, and therefore lib B dependencies C&D etc etc etc. Madness. If you do dependency managem…

> Maven isn't Java.

The wheels aren't the car. Sure, try to drive around without wheels.

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

#332

Post by kaba0 »

Kwpolska wrote: post #271
pjmlp wrote: post #78

Earlier quoted context omitted.

We are at Java 20, when Sun died we were stuck in Java 6. No improvements, what a joke.

Version numbers are extremely arbitrary, and Java has a new number every 6 months. If you compare Java 6 (2006) and Java 20 (2023), and then look at C# 3.0 (2007) versus C# 11 (2022), C# has gained many more features and improvements than Java did over the years.

Gaining features without bounds is not a positive in case of a language. C# is a very good language, but they really do copy C++ in adding everything under the Sun to it, and the complexity of managing it all can easily crumble under even good developers.

Java may be the other side of it, but I think it is a safer bet.

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

#333

Post by layer8 »

lenkite wrote: post #182
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…

If you wish to avoid JRE, you can use Graal VM and compile to native AOT executables. Just takes a few minutes to download and play-around. (Even timed it with another Java disbeliever here on HN) https://www.graalvm.org/latest/reference-manual/native-image...

You can’t use anything reflection-based I think.

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

#334

Post by datadeft »

lenkite wrote: post #191
datadeft wrote: post #45

Earlier quoted context omitted.

There are legitimate reasons to chose Go over Java, starting with the build system and the amount of effort needed to produce a single binary. I use Java for 20 years and Go for ~2. I am not actively hating Java but I value my time, specially that was wasted on maven + co.

"..and the amount of effort needed to produce a single binary." A couple of minutes ? Even timed this with another HN Java disbeliever who said its too much effort.

I understand that you mastered producing a single binary with your favorite build tool. In my experience if a language does not have an official way to build projects it does end well. Go, Rust and Zig are the prime example that a language should not be separated from its build system.

How to produce a single binary:

    go build


    cargo build


    zig build


  
  ...
  
    
      
        org.apache.maven.plugins
        maven-shade-plugin
        3.4.1
        
          
            package
            
              shade
            
            
              
                
                  classworlds:classworlds
                  junit:junit
                  jmock:*
                  *:xml-apis
                  org.apache.maven:lib:tests
                  log4j:log4j:jar:
                
              
            
          
        
      
    
  
  ...
Can you spot the difference?

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

#335

Post by layer8 »

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

Virtually no one has trouble with this in practice. You use OpenJDK unless you have “special needs”.

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

#336

Post by doctor_eval »

jeroenhd wrote: post #43
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.

I think Java is an ugly language riddled with roundabout ways of implementing modern features, but I can't fathom why anyone would pick Go over Java. It's slightly worse in almost every way other than writing shell scripts or massively parallel workloads from scratch. In my experience, Java's problem is the same as C++'s when Java began to take over: you usually encounter it in projects stuck at ancient runtime versi…

I wrote Java code for 20+ years and I can tell you exactly why I prefer Go: it produces native binaries.

I mean, it’s also less verbose, easier to start a new project, faster to startup, has far fewer configuration knobs, has native dependency management, is far easier to build CI/CD for, compiles more quickly, has very few NPEs gotchas, has value types, and avoids idiomatic boilerplate.

Go is far from perfect, but it has clear advantages over Java and I would not go back.

But the thing I love the most is the lack of a JRE. If I build for a target, it runs there.

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

#337

Post by haspok »

tm-guimaraes wrote: post #211
kaba0 wrote: post #82

Earlier quoted context omitted.

> The most popular one is Spring, and it's a pain, with abuse of reflection and magic, bad docs, and other issues How is it any different from something like RoR or Django, both of which are well-liked?

Depends if they are talking about Spring the framework, or Spring Boot, the "conventions bootstrapper" Both of them do not have bad docs, maybe some sub project might have, but compared to RoR (sorry never used Django), Spring's projects docs are magnificent. Their problem could be navigation for someone new to it, or in the case of Spring Framework, just too much concepts. So, Spring Framework is basically "make eve…

> Both are full of reflection. That's how it keeps being very generic at its core.

Reflection is not a feature, but a kludge - to conceal how non-expressive the core language is. Add annotations to that, and you might start asking yourself, what value does exactly Java's static type system add here, compared to a dynamic language (say Javascript)? Most of your errors will remain undiscovered until runtime, so why bother?

Things are changing for the better with Java, of course, with the speed of a glacier, but I don't think we'll ever be able to get rid of Spring proxies, or annotations or reflection.

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

#338

Post by kaba0 »

aembleton wrote: post #330
aardvark179 wrote: post #286

Earlier quoted context omitted.

Scala and Kotlin just implement them using a trampoline, the JVM does not itself support tail calls.

How do they do that? I thought it would need to be done at the JVM level so that stack didn't grow.

Every recursion can be converted to code that uses only a single stack. Tail calls can be easily eliminated at compile time automatically as well, that’s why it only needs compile-time support — I don’t specifically know what Scala/etc do, but the mentioned trampoline is basically just a function pointer one can jump to, accumulating results in some non-stack data structure if needed.

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

#339

Post by kaba0 »

maxbond wrote: post #48
marginalia_nu wrote: post #18

Earlier quoted context omitted.

Well, yeah. Haskell is a research language, while Java's stated design philosophy from day one has been to be conservative with adding new features, and judiciously add new features after they've proven useful in other languages.

To be fair though M:N threads aren't the provenance of research language, Go and Rust both have them, and I'm sure some other languages. (But it's awesome Java has them now too, other languages getting the feature earlier doesn't really devalue it.)

Rust doesn’t have them, though.

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

#340

Post by the-alchemist »

nicktelford wrote: post #324
layer8 wrote: post #317

> However, due to the large number of virtual threads that can be created, developers should use thread-local variables with caution. What is the problem here? Just the per-virtual-thread memory consumption by the variable when it is used (which would be expected)?

Lock contention IIRC

Yeah, poor performance and memory usage. In the Java world, thread locals are java.lang.ThreadLocal, basically a hashmap from thread to variable.

Using a ThreadLocal is (usually) a code smell. It's optimized / supposed to be used with just a few threads, not millions.

Post reply on HN