Earlier quoted context omitted.
Irrational Fear of Java is one of the most confusing things among startup stage companies.
Not fear. Disgust.
that's a ridiculous attitude.
Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
541–550 of 555 posts
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#542Earlier quoted context omitted.
Irrational Fear of Java is one of the most confusing things among startup stage companies.
Irrational Fear is actually what is waged on the Java front. People doing mental gymnastics to avoid touching anything non-Java. Cargo-culting. I've witnessed Java devs proposing changing an existing Go project's build system to maven because "that's what they know well". Straight insanity. People that avoid Java don't do it because of some stigma, but because they have been burned before. Remember that a typical Jav…
I work in a Go shop and we try to get rid of non-Go parts of our stack to make things simpler and more consistent.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#543Earlier quoted context omitted.
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.
I've used Java since it came out and I have never used Maven
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#544Earlier quoted context omitted.
Because Java did not have a good async model for decades, most Java apps are thread-intensive (thread-per-client) and there's an enormous amount of code that can't easily be refactored into async. Light-weight threads help save all that thread-per-client code from the ash pile of history. But in general it's best to write async code from the get-go because that forces the programmer to compress application state rath…
We are made of meat. It’s rarely worthwhile to sacrifice developer effort to conserve hardware, and if you do manage to break even today, you probably won’t in the future. Async Java was pretty painful and only penciled out because the cost of a million native threads was just ludicrously higher than everything else.
Yes, for Java the ergonomics of async will probably never be there. More generally however, it doesn't have to be so.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#545The issue I see is some companies' reluctance to even shift from Java 8 or move away from legacy.
I guess that will be the biggest impediment to adoption of new features.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#546Earlier quoted context omitted.
As long as virtual threads retain an entrypoint of control flow (e.g. return point from an I/O call), they will also be GC roots. They might not be very deep but they are GC roots. When a call returns, locals and parameters back up the stack will be expected to be live. Since there's no way in general to create a reference to a stack using JVM instructions (unlike .NET), the stack of every live thread must be a GC ro…
No, they are most certainly not GC roots, a fact you can actually observe in a program as described in the JEP ( https://openjdk.org/jeps/444#Memory-use-and-interaction-with... ). If you want some more detail, when a virtual thread is in the runnable state, it is reachable from the scheduler (which itself is a Java object, and not a GC root); when it is blocked on a lock or IO, then the lock object or the IO mechanis…
Interesting to read. It's a technical distinction with a primarily implementation difference, which I don't yet understand (i.e. have not taken the time to read yet), but I infer from the fragment that I did read, that there is some degree of semi-magical hoop jumping going on to make the CPU stack live in a Java heap object to which a reference can be taken in Java code.
Objects are obviously rooted for blocked virtual threads that may resume - a formal understanding of them being GC roots - but the implementation appears to be by taking a reference to the heap object containing the stack at the moment of being blocked, presumably by a JVM native method or similar.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#547Earlier quoted context omitted.
No, they are most certainly not GC roots, a fact you can actually observe in a program as described in the JEP ( https://openjdk.org/jeps/444#Memory-use-and-interaction-with... ). If you want some more detail, when a virtual thread is in the runnable state, it is reachable from the scheduler (which itself is a Java object, and not a GC root); when it is blocked on a lock or IO, then the lock object or the IO mechanis…
Interesting to read. It's a technical distinction with a primarily implementation difference, which I don't yet understand (i.e. have not taken the time to read yet), but I infer from the fragment that I did read, that there is some degree of semi-magical hoop jumping going on to make the CPU stack live in a Java heap object to which a reference can be taken in Java code. Objects are obviously rooted for blocked virt…
> Objects are obviously rooted for blocked virtual threads that may resume
If by "rooted" you mean reachable in the object graph when starting the traversal from the roots, then yes. If a blocked thread isn't reachable, there is no way to call its unpark method that resumes it.
> the heap object containing the stack at the moment of being blocked, presumably by a JVM native method or similar.
Yes, we implemented virtual threads on top of continuations that, in turn, are implemented inside the VM. Their stacks are reified as heap objects.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#548Earlier quoted context omitted.
That's the point of Java's virtual threads, basically nothing* will block. The JVM can simply replace a blocking user IO call to an async one under the hood, and in the meanwhile schedule another virtual thread to work. When the IO is ready the suspended thread might get continued. * FFI has to be pinned, so it will block
In your example the thread is not blocked but the callers are blocked. There is more to async/await than simply keeping os threads unblocked, they also provide a mechanism for keeping callers unblocked and synchronizing async contexts(parallel or concurrent). Is Loom addressing this need? Otherwise it's Goroutines(or any green threading solution) without channels and select. The ecosystem will fracture around solutio…
Java allows not blocking callers using Futures or callbacks for a long time.
As well as Promises and callbacks were available in Javascript before async / await.
var executor = Executors.newVirtualThreadPerTaskExecutor();
;; or, for old Java
var executor = Executors.newSingleThreadExecutor();
Future f = executor.submit(someFunc);
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#549Earlier quoted context omitted.
Well, I listed a number of things I prefer about Go, and the verbosity I was talking about was the classic ButtonFactoryFactory and other naming classics. It’s true however that I ended up throwing that stuff away from my Java code and started to enjoy life again. But I can say honestly that I prefer Go’s error handling, which I find tends to result in errors which are actionable. I think it takes a lot more effort u…
Name one FactoryFactory in the JDK
FactoryFactory is (or was) a well known parody of the multiple levels of abstraction Java developers were encouraged to make when performing even simple tasks. This started with an insistence that we should use getters and setters for field access, and it basically went downhill from there.
This kind of nonsense was endemic to the Java engineering culture while I was working in it.
Perhaps the worst example I saw was during the fluent API craze where someone in my team replaced a constructor call for a Button with five lines of fluent Builder pattern gibberish.
The point of mentioning FactoryFactory was to poke fun at the culture surrounding Java, which ended up being one of the reasons I stopped using it, because idiomatic java stopped making sense to me.
Hopefully it’s changed now.
Re: Virtual Threads Arrive in JDK 21, Ushering a New Era of Concurrency
#550Earlier quoted context omitted.
A few counterpoints: - Modern Java requires heavy use of Decorators - JSON handling is tiresome - As soon as you are using Spring you aren't actually coding Java anymore - Many mature libraries have dated APIs - Similar functionality is often implemented multiple times in multiple different libraries. Can be confusing if you start out. - Java requires a well configure IDE - However, IDE Support won't matter in a year…
> For the use cases I work on I'd prefer Go for its simplicity Why don’t “enjoy” the simplicity of assembly then? (Not trying to be sarcastic, just I always felt that this logic is flawed. Especially that java is a very simple language, with very few concepts. If you don’t like, you absolutely don’t have to use metaprogramming like Spring)
Yes, Java is a simple language. But all the stuff that was added to Java makes it at times feel bloated and annoying to work with.
> Why don’t “enjoy” the simplicity of assembly then?
Now thats just stupid.