18 ms·
Java Virtual Threads Preview
- saasaccount2 5y agoso true and practical approach.
- ksec 5y agoIs Virtual Threads part of Project Loom? i.e We expect Project Loom to land a little bit after this or are they completely separate issues and Project Loom is still far from landing?
- aardvark179 5y agoJEPs are the mechanism by which projects deliver changes. This, and two other JEPs form the bulk of the work done as part of Loom, along with a number of other connected JEPs mentioned in this one.
- jmartrican 5y agoAs part of project Loom, these green threads were called Fibers, not VirtualTheads. Did they change the name?
- aardvark179 5y agoYes. As ideas were prototyped it became clear that Fibers needed to be Threads or there would be too many rough edges regarding compatibility and concepts that developers would need to keep in their heads.
- ksec 5y agoThanks for the explanation. A little hard for those who do not follow it closely.
- he0001 5y agoIs this project loom finally delivering?
- SureshG 5y agoThere are two more intersting features that work with Virtual threads, Structured Concurrency - https://openjdk.java.net/jeps/8277129 https://openjdk.java.net/jeps/8277129 Scope Locals - https://openjdk.java.net/jeps/8263012 https://openjdk.java.net/jeps/8263012
- mpbeauj 5y agoHopefully this kills the ridiculous trend to write all functional, reactive Java apps by providing a normal way to do non-blocking API calls...amazing news!
- bitwize 5y agoGreen threads are back!
- abraxas 5y agoFar fewer applications need this than many are led to believe. That said, this is always a welcome addition although this really doesn't add more than syntax over the stuff we've had in java.nio for a couple of decades
- closeparen 5y agoYou can always write a callback oriented program, but this is much nicer!
- abraxas 5y agoYeah agreed. It is definitely very welcome syntax sugar and I'll take it over JS callback hell or async/await stuff any day. I just wanted to point out that non-blocking I/O has been available in Java for a long time so high I/O throughput applications have been possible to build in Java even though it required more mental overhead.
- nhoughto 5y agoMore mental overhead and tough ecosystem, you end up in the coloured functions problem where you choose to write non blocking code so now all your dependencies / libraries must too. Nodejs worked because it was like this from day 1 but java isn’t. This change would make the base primitives non blocking (really cheap Blocking which is better) by default, so now you can use any~ library and it should just work. Waaay better.
- sgift 5y ago> Nodejs worked because it was like this from day 1 but java isn’t. And even there "worked" is a very liberal definition. Callbacks, promises and whatever else you can find will imho never be as intuitive as threads.
- nhoughto 5y agoyeah it worked, as in the ecosystem was consistent with a single non-blocking pattern.. and then almost immediately went in 5 different directions around how to program around it.. callback hell, async/await, generators, promises etc..
- zz865 5y agoI was going to say with modern PCs this is kinda redundant now, but its still a language of small devices too, where it'll be welcome.
- jzoch 5y agoThis isn't really targeted for small devices - its very very applicable with large computers in datacenters (id argue those machines will benefit even more from this). Any time you wait on I/O you potentially park an entire thread when you could be multiplexing your threads. This is a net win for almost all users of threads (except perhaps 100% cpu intensive tasks)
- zz865 5y agoYou can do that now already though, the main expense is 1mb of memory for stack.
- Skinney 5y agoUp to 1mb of stack memory. It starts lower, only consuming what it needs. It doesn’t resize down again, though, which virtual threads do. The other cost is context switching, which is much cheaper with virtual threads.
- Twisol 5y agoI'm salivating over the context switching wins, myself. I've got a simulation system that uses threads to pause and resume modeled tasks at the appropriate times relative to the simulation clock, and we're just passing a token back and forth with each step of a task. These threads aren't used for parallelism; they're just used to capture the task's continuation in a convenient way, allowing us to use a direct-style approach to modeling tasks. The context switching sucks so much that an alternate approach, swapping threads for throwing an exception on yield and re-running the method and ignoring side-effects until we get back to the resumption point, saves us a significant amount of time.
- 5y ago
- hn_throwaway_99 5y agoReally excited to see this! Seeing some of the early comments here I think folks may not realize how awesome this would be in the server space. After all, a big reason that NodeJS won a lot of popularity on the server is that, for many types of common webserver workloads (i.e. lots of IO, relatively minor CPU usage), NodeJS can actually scale much better than Java with its thread-per-request model. With these virtual threads, though, you could get the best of all possible worlds - a webserver that scales like NodeJS, but without some of the "CPU starvation" issues you can hit in Node if one executing request doesn't yield, and also without having to worry about "function coloring" like you do in Node with async vs. non-async functions. Really, really fantastic development, have been waiting to see when this would come out.
- tannhaeuser 5y ago> NodeJS [...] with its thread-per-request model Node.js doesn't create a thread per request; it's single-threaded with evented I/O. You can use node-cluster to start more than a single thread to saturate multi-core CPUs and load-balance HTTP requests across these, but that doesn't make it thread-per-request.
- an_account_name 5y agoSuspect they're talking about Java - a lot of frameworks do exactly create a thread per request.
- didibus 5y agoI can't think of any framework that still does one thread per request. Normally there is a a queue of incoming requests and they then get dispatched on a thread pool as threads return to the pool. The challenge is normally that if any of the threads in the pool, as part of processing a request, needs to itself make an IO call, it will block. Ideally you'd want to park the request processing, return the thread to the pool, pick up the next request, until the IO is done where then on the next thread available from the pool you'd resume that request instead of picking another one. This is what the virtual threads will make really easy I think.
- whalesalad 5y agoI was just thinking I’d love this element of Erlang/BEAM with the syntax of Clojure (lisp). This makes that sound more possible.
- pdpi 5y agoHave you looked into Lisp-Flavored Erlang? https://lfe.io/ https://lfe.io/
- anonymousDan 5y agoYeah I wonder would this potentially simplify the implementation of something like Akka?
- touge 5y agoWhy not just use a name like 'Joroutine'
- geodel 5y agoMaybe because it sounds terrible.
- didibus 5y agoThey're not coroutines though. This is a little semantic, but a coroutine normally uses cooperative multitasking exclusively. Something like: coroutine foo while queue not full put something in queue when full yield bar coroutine bar while queue not empty take from queue do something with what was taken when empty yield foo Each time the coroutine yields, it removers it's state and execution resume another coroutine, and when execution is yield back it too resume from the yield point. As I understand, in Java, they are not adding coroutines, but something that is a virtual thread, which is more like a green or lightweight thread. It means that it can be pre-emptively paused and resumed, it doesn't have to voluntarily yield. There is some scheduler that could decide when to execute which virtual thread and so on.
- Twisol 5y agoRight; Java's virtual threads are (*adjusts glasses*) preemptively-scheduled stackful continuations, meaning (1) that they execute in parallel and in cooperation with the OS' scheduler (*) (which automatically timeslices the CPU amongst threads), and (2) that each continuation is the full call stack at its yield site. The alternative for point 1 is cooperative scheduling (announcing explicitly when they yield), as you've described. The alternative for point 2 is "stackless" continuations, where the task yields by returning a callback describing the next step of the task -- or, equivalently, returning some data describing the state of the task, which the task's primary entry point can use to decide where to continue from. (For instance, imagine a function with a big `switch` statement that, when invoked, decides which case to jump into based on its argument, which the caller got from the return value of the last time it got invoked.) Either way, every step of the task constructs and then returns out of its call stack, which can be much more memory efficient, but is also more painful to model tasks in without help from the compiler/language. (*) Technically, the JVM could take on the role of scheduler as well; it could count the number of bytecode instructions executed, say, and pre-empt a task after some number. This is what Lua supports for some of its sandboxing capabilities. But I think that would be counter to Java's use of an OS thread pool to execute these virtual threads; its own scheduler would be interleaving somewhat unpredictably with the OS'. You'd want to do that if you have long-running jobs that do little I/O (so they hog an OS thread)... but then you'd probably rather put those jobs on actual background worker threads.
- emmanueloga_ 5y agoYT talk from Ron Pressler: "Why user-mode threads are (often) the right answer" [1] and slides [2]. 1: https://www.youtube.com/watch?v=KmMU5Y_r0Uk https://www.youtube.com/watch?v=KmMU5Y_r0Uk 2: https://assets.ctfassets.net/oxjq45e8ilak/5QM86VAnN9XJ9HUIs2er5v/8240f681da10461f7d63a83429c90e4c/JPoint2021Loom.pdf https://assets.ctfassets.net/oxjq45e8ilak/5QM86VAnN9XJ9HUIs2...
- zvrba 5y agoSomeone would disagree (though in context of C++): http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p1364r0.pdf http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2018/p136... Perhaps it's easier to address the problems in a managed environment and I really do hope they pull it off. Also it's unclear whether virtual threads will support async file I/O out of the box, or ever. (C# does have Async methods on files.)
- pjmlp 5y agoC++ still needs to get the executors mess sorted out. Java supports executors since Java 5, and async IO exists since ages with NIO. Nowadays C++ gets lost discussing language minutiae that it isn't as much fun as it used to be.
- zvrba 5y ago> Nowadays C++ gets lost discussing language minutiae that it isn't as much fun as it used to be. Yeah, I agree. C++ is no longer fun at all.
- yla92 5y agoI wonder how this gonna compare with Kotlin Coroutines[0] 0: https://kotlinlang.org/docs/coroutines-overview.html https://kotlinlang.org/docs/coroutines-overview.html
- lmm 5y agoIt's like an implicit, magic version of them. If the implementation is perfect then it will work great and make Kotlin coroutines obsolete. If the implementation isn't perfect, everything will work great until it hits whatever corner case and blocks everything (just like when you block on a coroutine without properly shifting to a blocking executor, only less visible and harder to diagnose).
- haimez 5y agoArguably more visible because you have native JFR support for noticing such an event. Let’s remember, that Kotlin is a guest language and that the host platform implementations get host platform integrations natively.
- lmm 5y agoIn my experience plain old userspace code is always the easiest thing to debug, so a guest language (where a large chunk of the runtime itself will be, by definition, just plain old code) often ends up easier to understand.
- haimez 5y agoIn general, I would agree with you- because Kotlin or Java that corresponds to your own code should be easier to find and understand than hotspot’s C++ source code or the jit output. Last I checked though, Kotlin was threading coroutine suspend/resume points into methods as part of bytecode generation (it’s been a while, please do let me know if I’m wrong on this) which is not something most engineers are ready to read in the simple case, much less when trying to interpret the compiler’s name mangling scheme. In either case, the implementation that ships with the JVM will be more capable because of it’s privileged position of integrating with the runtime, so good news! Eventually Kotlin might be able to use the native facility.
- geodel 5y agoSince currently it is not targeted to any JDK version. I think at the earliest it will be Java 19 to be out in Sept 2022.
- Twisol 5y agoThat would be my guess as well, and I would (casually, sitting in my armchair) expect two previews for such a significant change to the JVM. I'm not expecting it to land fully until Java 20 at least -- but we should absolutely give the previews a try as they come out.
- sverhagen 5y ago...and then many of us may not put it in production until the next LTS anyway... (...aside from those that are perpetually stuck on Java 8 anyway.)
- Twisol 5y agoI'd love to know who, of those pinned to an LTS release, has actually made use of a support contract with a company providing contracted support for an LTS release, whether it's Oracle or another company. I don't doubt they exist, but I have no idea what that support even looks like. My team has been happily tracking the twice-yearly JDK bumps. We started development three years ago against Java 8 and made a series of jumps (9, 11, and then 14 onward) and never really had an issue. I'm not sure I can live without `var`, `record`, and pattern-matching `instanceof` anymore. (With `sealed` interfaces and records, the visitor pattern is long gone... I can only wait with baited breath for exhaustive pattern-matching `switch` expressions.)
- msla 5y agoMore information: https://en.wikipedia.org/wiki/Green_threads https://en.wikipedia.org/wiki/Green_threads Which makes me wonder how this is new: > In Java 1.1, green threads were the only threading model used by the Java virtual machine (JVM),[8] at least on Solaris. As green threads have some limitations compared to native threads, subsequent Java versions dropped them in favor of native threads.[9][10] So is the "new" part that green threads are coming back to Java?
- jmgao 5y agoThe "some limitations" there was mostly that original green threads implementation in Java lived on a single OS thread, so you could only use one core. Presumably that's changing this time around?
- Twisol 5y agoYes, by my reading of the linked JEP, these virtual threads are executed by a pool of honest-to-goodness OS threads (so a virtual thread might pause on one thread and get resumed on another).
- Const-me 5y ago> at least on Solaris On Windows NT as well. On my first job around 2000 I did a little bit of Java programming. As far as I recall, JVM scheduled all their threads on top of a single OS thread.
- 5y ago
- daxfohl 5y agoAwesome, now that we've just spent a year rewriting our backend with callback hell to make it async, we can spend the next year rolling it all back.
- sandGorgon 5y agoInterestingly, Kotlin Coroutines have been available and in production for a LONG time now. https://github.com/Kotlin/kotlinx.coroutines https://github.com/Kotlin/kotlinx.coroutines In fact, Kotlin Coroutines are an brilliant on the android platform. We are talking severely memory and CPU constrained architectures here. That said, Kotlin Coroutines are popularly used in production on server side - https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/ https://vertx.io/docs/vertx-lang-kotlin-coroutines/kotlin/ I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. Maybe Kotlin will leverage this in its underlying infrastructure.
- kjeetgill 5y ago>I doubt anyone would switch to Java Virtual Threads anytime soon, unless via Kotlin. I think you're mistaken. The Java community is just so tremendously larger relative to the Kotlin one, that this will have more users within months. I really liked what Kotlin was doing, but Java since got lambdas, they have closed the biggest gaps that drove migration.
- shrewduser 5y agoLambda's seem like one of the least interesting features of kotlin. There's so much more going on in the kotlin world than lambdas. it seems to me that kotlin is leading the way and java is following, but the delta between them is quite large and possibly growing.
- kjeetgill 5y agoI'm not disagreeing with what you're saying here — at all. But what I am claiming is that when it comes to interest for and adoption of Kotlin within the JVM community that pull is smaller and shrinking. And that lambdas in Java are a big part of the reason for that.
- kaba0 5y agoKotlin never had any real pull on the behemoth that is Java. It’s an insignificant language (outside android, where java is not the real deal to begin with). If anything, JS and C# and other major high level languages could hurt java, but fortunately it has been developing in a fast pace, implementing whatever is worthy and was experimented by other languages.
- polskibus 5y agoIs this like .NET tasks? If so, what’s the async story here? Does it involve function colouring like in .NET?
- vips7L 5y agoIt does no function coloring. Just block :). Virtual threads are preemptive not cooperative.
- kaba0 5y agoIt doesn’t block, that’s the whole point. The runtime knows if a given method is blocking or not and under the hood even blocking IO calls are implemented with non-blocking IOs. So those can be preempted.
- vips7L 5y agoYes I know. “Just block” refers to just waiting on virtual threads/futures via get or join. No fancy observables or callbacks etc.
- grandiego 5y agoIn the "Alternatives" section of TFA there are some interesting comments regarding the async/await approach (which was avoided by the Virtual Threads proposal): "Provide syntactic stackless coroutines (async/await) in the Java language. These are easier to implement than user-mode threads and would provide a unifying construct representing the context of a sequence of operations, but that construct would be new, separate from threads while being similar to them in many respect yet different in some nuanced ways, would still split the world of APIs between those designed for threads and those designed for async/await, and would require the new thread-like construct to be introduced into all aspects of the platform and its tooling, resulting in something that would take longer for the ecosystem to adopt while not being as elegant and harmonious with the platform as user-mode threads. Most languages that have chosen to adopt async/await have done so due to an inability to implement user-mode threads (Koltin), legacy semantic guarantees (JavaScript), or language-specific technical constraints (C++). These do not apply to Java." I wonder if Rust should also be included in the final sentences.
- cryptonector 5y agoThere is a spectrum of solutions for dealing with slow I/O in programming languages (well, all I/O is best assumed to be slow I/O). At the two ends of the spectrum are: - continuation-passing style (CPS), hand-coded or compiler - preemptive threading / processes In between lie various solutions, like async/await (closer to CPS), and green threads (closer to preemptive threading). The key difference between the two ends of this spectrum is memory footprint. With CPS you manually compress state into tuned structures. With threads you store state all over the stack in very inefficient ways because all those stack frames take extra space. Any solution towards the thread side of the spectrum will yield significantly larger memory footprints than solutions towards the CPS side of the spectrum. On the other hand, solutions towards the CPS side of the spectrum can require writing application-specific schedulers if fairness issues arise. On the whole, solutions on the CPS side of the spectrum are better, IMO. Java is kinda stuck with threads, so green threads make some sense. Of course, you can get pathological issues in M:N threading, so be careful about that.
- rzwitserloot 5y ago> Any solution towards the thread side of the spectrum will yield significantly larger memory footprints than solutions towards the CPS side of the spectrum. The community-at-large decided that hand-tuning garbage collection was too finicky and not worth it, even though it obviously 'costs' memory. I'm frankly at a loss as to why so, so, so many blogposts and tech experts are all-in on the CPS-side of this argument; it seems quite obvious to me that in the vast majority of cases, the considerably simpler* model of (green) threads means you're making the exact same trade-off: Simpler to write and debug code at the cost of needing more memory when running the app you write. *) For sequential/imperative-style languages, that is. If you're writing in a language that is definitely and clearly intended to be written in a functional style, I can see how the gap between CPS-style and threading-style is far narrower. However, java, python, javascript - these are languages where the significant majority of lines of code written are sequential and imperative in nature. Also note that in e.g. java you can actually configure stack sizes as you make threads. Thus, your choice of words of "'significantly' more memory footprint" is debatable.
- 5y ago
- amitport 5y agoDoes anyone know if delimited continuations are on the roadmap with this? Potentially, virtual threads enable them (assuming a serializable environment) (co routines are also enough for this, the serialization capability is what I find interesting). This will enable a complete freeze of an execution to be stored and even send over the network to be completed somewhere else.
- clhodapp 5y agoThe idea of serializing suspended computation across a network seems extremely attractive to a lot of people but I've never understood why it's so appealing versus the more typical approach of sending whole binaries and defining messaging protocols. Could you possibly elaborate on why this capability is exciting?
- amitport 5y agoFor me. Code expressiveness and Simplicity. If you can just send the computation around your basically don't need the entire message/protocol boilerplate in your execution code. For example, think of a game engine that allows to write code with loops and calling function that may wait for an event or a rule to be true. Imagine that your game can be paused stored in case of a connection lost, synced between different server or both at a server and at a client for fast response. Now without this language feature your basic game logic code gets, you can just have a wait statement inside a loop etc., How will you return to the same place on resume? You need more code, storing the entire execution state.. on every condition or a loop you either need to store something or have code that looks like a state machine etc., With this feature you don't need special design pattern, just write it, and the mess is in the language level.
- jrh206 5y agoI really hope they change this `Thread.ofVirtual()` and `Thread.ofPlatform()` language; it sounds clunky and doesn't read like any Java that I've seen before.
- ljnelson 5y agoIndeed. “of” infected Java with the awful naming conventions imposed by java.time (and to a lesser degree java.nio) because “new” is a keyword and doing “newThing” instead was not in vogue. Now it smacks of the worst kind of hipster disease and is going to enter java.lang for no good reason at all. What’s wrong with “newPlatformThread” or something similar? This shouldn’t have survived the initial sniff test.
- Twisol 5y ago`Optional.of`, `List.of`, `Set.of`, `Map.of` (and `Map.ofEntries`), ...; this language is actually pretty settled into the JDK.
- elygre 5y agohttps://blog.joda.org/2011/08/common-java-method-names.html?m=1 https://blog.joda.org/2011/08/common-java-method-names.html?... has some background into the logic of static factory naming, covering from() and of().
- halayli 5y agohuh, they invented a new virtual vocabulary here and beat around the bushes to avoid saying coroutines. Sarcasm aside, it's probably to steer away from kotlin and make it easier for users when seeking help/docs online.
- bedatadriven 5y agoThis is primarily a change at the virtual machine level that will also benefit kotlin and other JVM based languages.
- Twisol 5y agoCoroutines are usually cooperatively scheduled (that's what the `co-` is for); these are pre-emptively scheduled, first by assignment to a pool of OS threads, and secondly by the OS' own thread scheduler. "Thread" is common nomenclature for pre-emptively scheduled tasks. "Virtual" is a little less standard, but it draws on existing patterns: they've virtualized threads in the same way that the OS virtualizes the CPU (timeslicing) and virtualizes memory (literally, virtual memory).
- anonymousDan 5y agoThey are not fully preemptively scheduled though right? If I have a virtual thread that enters an infinite loop it will not be possible to reclaim its host OS thread no?
- Twisol 5y agoThat's a good question. It's not very easy to do that with regular Java threads either, though [0], and I think everybody considers those "fully preemptively scheduled". Preemptive scheduling is more about whether the scheduler (in this case, the OS scheduling the carrier threads) can pause a thread no matter where it is in its processing, and since virtual threads are executed by OS threads (the virtual part is just the JVM tracking the context and where to resume at), they're preemptive. [0] https://stackoverflow.com/questions/671049/how-do-you-kill-a-thread-in-java https://stackoverflow.com/questions/671049/how-do-you-kill-a...
- truth_seeker 5y agoI am lost here. the non-goal mentioned here are actually worth taking as goals to be fulfilled so that every other language and library ecosystem which runs on JVM will get benefited. Non-Goals:- It is not a goal to change the existing implementation of platform threads, that represent Operating System (OS) threads. It is not a goal to automatically convert existing thread construction to virtual threads. It is not a goal to change the Java Memory Model. It is not a goal to add new inter-thread communication mechanisms. It is not a goal to offer a new data-parallelism construct in addition to parallel streams.
- truth_seeker 5y agoIts impossible say anything unfamiliar thing on HN, all kinds of morons are active all the time on HN to donwvote. ;) keep it up.
- kaba0 5y agoI did not downvote, but I guess you got those mostly because it was more of a statement on your part instead of a genuine question.
- vincnetas 5y agobackwards compatibility?
- invalidname 5y agoThose all make sense: - Native threads are great. They have a lot of uses, why touch them - Automatic conversion will break a lot of stuff and eliminate some of the benefits of native threads. Being able to use an API/implementation that is *almost* the same is a huge beneift - The memory model is a completely separate thing that Java worked on for decades. You don't want to touch that and you don't need to - Inter-thread communication is a separate thing. There's no reason to go after that. Same is true for the data parallelism stuff. The focus should be on hitting the 98% of what matters and getting it out without breaking everything we already have.
- 5y ago
- Matthias247 5y agoI'm curious about > There are situations when the VM cannot suspend a virtual thread, in which case it is said to be pinned. Currently, there are two: > When a native method is currently executing in the virtual thread (even if it is calling back into Java) Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking? What if I e.g. want to call a library that is known to be non-blocking, or make a syscall that is non-blocking which is not pre-wrapped by the Java standard library? E.g. a library that allows to offer interacting with a BPF map comes to my mind. Is there maybe an escape hatch for virtual thread aware java libraries, where they can tell the runtime that they want to call native code without extra guardrails and overhead?
- aardvark179 5y agoYou aren’t incurring any overhead because that native code isn’t going to try and yield execution. You would only incur the overhead if the code called back to Java, and then that Java code performed some blocking operation.
- Twisol 5y ago> What if I e.g. want to call a library that is known to be non-blocking, or make a syscall that is non-blocking which is not pre-wrapped by the Java standard library? My understanding is that pinning only enters the equation if you need to yield while a native frame is on the stack. If that call is non-blocking, then by definition you'll call into it and return without needing to yield the current task. A non-blocking call should give you some way to tell when the job you've requested has completed, of course, and then you need to either poll for it or arrange to be told when it's done. You don't want to spinlock in a virtual thread (you're just hogging an OS thread continuously, which is exactly what pinning is), so either way, you'll end up blocking -- but as long as you're blocking after returning from the native call, you should be fine. > Does that mean any kind of native code is currently paying some extra cost due to the possibility of being blocking? I have no special insight, but I imagine any costs are only incurred if a yield actually occurs with native code on the stack. Only then would the yield logic pin the current task to the current thread.
- moring 5y ago
- moring 5y agoA key point that I was particularly happy about is that ThreadLocals work well with virtual threads. My personal killer application: MDC for logging. I have just tried to build proper logging into a Javascript/Typescript application and none of the logging frameworks support MDC (or need cumbersome workarounds) because the async-isms in the underlying language prevent it from working as intended.
- aardvark179 5y agoThread locals work, but we think in scope locals we have a better more robust mechanism more suited to the way thread locals are used in things like logging libraries.
- yutijke 5y agoAnyone know if this preview JEP would make it into Java 18? We've been hearing out openjdk's project loom for a while, but we haven't gotten to try this out in Java mainline. I am guessing this will take at least two previews before an initial release. And given the speed the ecosystem moves at, we may not see this reaching widespread use for quite a while.
- jpgvm 5y agoIt's very close but I wouldn't expect it in 18, much more likely to land in 19 as preview. I have been using Loom builds for a small app for a while and haven't encountered anything strange (though last time I checked virtual threads confused the crap out of my IDE debugger) so I expect that there should be very few bugs to fix and thus should have an easy path to LTS in Java 21.
- dikei 5y agoThis can't come soon enough, virtual threads is definitely simpler to write and read than manually breaking your logic into Future and Promise.
- bborud 5y agoI've watched some of Mark Rendle's talks (like this one https://youtu.be/2-mFWi5oLkM https://youtu.be/2-mFWi5oLkM) and while watching it I realized how much I dislike when languages start to absorb ideas that are either alien to the language, or offer multiple paradigms for solving the same problems. I can understand Java programmer want the goodies offered in languages that are more geared towards concurrency. But multiparadigmatic languages really suck because they are no longer a single language. You get islands of different practices and a partitioned set of practitioners. And they can't always use each other's code (C++ being the most extreme and painful example). This makes me kind of glad I switched to Go 5-6 years ago. And it makes me wonder when the (good) intentions of the Go designers to not absorb every idea that comes along will go out the window and Go will start to grow knobbly bits all over.
- dastbe 5y agoyour comment surprises me, because this kind of development is explicitly trying to avoid bifurcating the language. i would argue that the async io/futures libraries that exist in java are the bifurcation because programming with them is very jarring compared to threaded java.
- jpgvm 5y agoHis comment bellies his clear ignorance to both the Java development process and Loom in particular. Such comments aren't unusual where Java is concerned, it's the one language where many are willfully ignorant (well PHP is also in contention). Pay them no mind though. Java is already the premier server side language for serious work and this is just another tool in the toolbox, hopefully I will see less RxJava in my future. :)
- bborud 5y agoYes, and I am hoping that Go won't go through the same. But if you think about how different languages have evolved they do, over time, tend to end up in places where it gets harder and harder to avoid.
- kccqzy 5y agoDoes Go have closures? Yes it does. Therefore you can start writing everything in an async style, manually passing closures around. Then build an executor interface. Voilà. Here's an utterly alien Go codebase that doesn't use green threads. It has nothing to do with language. It has everything to do with how other libraries (especially standard libraries) structure their code.
- Nullabillity 5y agoThreads as an API have proven themselves over and over to be unfit for human usage (regardless of whether they're M:N or 1:1), and higher-level async libraries have already had M:N scheduling for years. This helps absolutely nobody. Why does Oracle keep throwing money down this pit?