10 ms·
Helidon Níma: A Java microservices framework based on virtual threads
- philonoist 3y agoElaborated here - https://medium.com/helidon/helidon-níma-helidon-on-virtual-threads-130bb2ea2088 https://medium.com/helidon/helidon-níma-helidon-on-virtual-t...
- sgt 3y agoThis is a killer "app" for Java 21. There's now little reason to choose Kotlin or some other language to build efficient API's etc.
- jfengel 3y agoWas there ever? What made Kotlin fundamentally different in that respect? Kotlin is great for fixing some legacy design oopsies (Java really should have been smarter about null and it can't be fixed without breaking legacy code), but I wouldn't expect it to do something that was impossible or it infeasible in Java.
- Tainnor 3y agoCoroutines are one of the most prominent features of Kotlin, so it does make sense to bring this up in the discussion. OTOH, I'm unconvinced that virtual threads make coroutines, reactive APIs etc. obsolete. Those are about structured concurrency, and with projet Loom, the structured concurrency proposal is still in the incubating stage.
- mikmoila 3y agoSC will be a preview level API in Java 21: https://openjdk.org/jeps/453 https://openjdk.org/jeps/453
- richbell 3y agoThe magic of Kotlin's structured concurrency is that it "just works" without you having to think about it, and it's difficult to screw up. This looks a fair bit more involved, though I'm excited for it nonetheless.
- zmmmmm 3y agoYes from a pure functional perspective, it's really down to null handling at this point. But kotlin has a lot of nice syntactic sugar still. Same with Groovy.
- Tainnor 3y ago> it's really down to null handling at this point. and reified generics, if you care about that sort of thing. Plus immutability/final by default, the stdlib being a joy to use, etc.
- pjmlp 3y agoWe all know how Groovy ended. Being syntax sugar isn't enough to keep a language going.
- brabel 3y agoWhat do you mean, how Groovy ended? It's still going strong with regular releases and continues to keep up with new Java features! It's a pretty nice language if you don't mind dynamic typing, which has its uses.
- pjmlp 3y agoNo one cares it exists, beyond Gradle scripts, Gradle saved the language to join fate with Beanshell, jTcl, jython,.... Long are the days where it was proposed to have parity alongside Java in Java EE, and Spring used to talk about it as it does with Kotlin nowadays. Or when Grails was a common subject of talk proposals at German JUG meetings.
- brabel 3y agoWell I care a lot that it exists. And many other people I know do as well. Just because you don't seem to like it, you shouldn't imagine everyone else is like you. Maybe Grails is no longer used as much (like Rails itself), but Groovy found other usages since then, like https://spockframework.org/ https://spockframework.org/ and Jenkins pipelines (https://www.jenkins.io/doc/book/pipeline/syntax/ https://www.jenkins.io/doc/book/pipeline/syntax/). It's not going anywhere, and I see no reason for anyone to be upset about it.
- 4RealFreedom 3y agoI write both Kotlin and Java but Kotlin is my go to. Kotlin's when statements alone are a reason to use it. Then there's the null safety, extension functions, built in lazy initialization, and smart casts. Kotlin is just a joy to write in.
- paulddraper 3y agoPlus...Kotlin is compatible with Java, so even a small improvement can still be reason enough to use it
- sgt 3y agoGood point. But getting Java devs (ie the rest of my team) to join in on the Kotlin fun has proven difficult.
- twic 3y agoI am looking forwarding to trying Nima. The blocker for me is IntelliJ supporting Java 21, which i believe will be this winter [1]; i don't absolutely need IntelliJ, but i am very lazy. At the moment, my apps are using either the JDK HttpServer, which is easy to use, but of questionable robustness and lacking websocket support, or a Netty-based server, which works very well and supports websockets, but is often awkward to program against because it's asynchronous. Nima should combine a nice simple synchronous API with a fairly luxurious feature set and good scalability. Of course, it will turn out there are things terribly wrong with it, because this is real life. But for now i'm optimistic! [1] https://intellij-support.jetbrains.com/hc/en-us/community/posts/13049784815250-Planned-release-date-of-2023-3-with-Java-21-support https://intellij-support.jetbrains.com/hc/en-us/community/po...
- Two4 3y agoNon-MicroProfile Helidon uses a reactive interface for most things, which lends itself well to async operations. It a very nice, simple and powerful abstraction that makes async relatively easy. IMO anything webserver or client should be async when virtual threads aren't available, due to Java having the tendency to quickly build up a ton of threads when you use the one-thread-per-request model. That being said, virtual threads does make that model viable at scale, so reactive async probably isn't as necessary.
- strangemonad 3y agoI’ve had no problems scaling jetty to 400-500 qps per node on small thread pools.
- mikmoila 3y agoJetty can be used with virtual threads: https://webtide.com/jetty-12-virtual-threads-support/ https://webtide.com/jetty-12-virtual-threads-support/
- Two4 3y agoAs soon as you start talking thread pools, you're talking about async task dispatching at some level, even if it's abstracted away at the API level. What I'm talking about is using a virtual thread, not event-driven shuttling of stateful objects between threads via task queues, to complete a request from start to finish.
- logicchains 3y agoGreat project but the name is very unfortunate for Chinese speakers.
- pandemic_region 3y agoCare to elaborate?
- phyrex 3y ago“Nima” could be read as “your momma” in mandarin
- twic 3y agoIt's a weird name, because it's a transliteration of the Greek word for "thread", which would conventionally be "nema" in English (as in nematode worms, nematocysts, Treponema, etc).
- logicchains 3y agoIt's the most common Chinese swear word, "your mother" (你妈）.
- meitham 3y ago“Zip” is penis in Arabic, so I remember at university our female colleagues would read it as an abbreviation “ZIP” zed-eye-pee to avoid the embarrassment!
- deleted 3y ago[deleted]
- pandemic_region 3y agoI'm not really grokking the code sample on their frontpage. What is it doing? Explain it like I am a Java developer with 18 years of experience.
- Tainnor 3y agoIt's referencing other variables and functions that aren't defined in that snippet. Presumably you can somewhat guess what it's trying to do (call a function for each element of the response), but it doesn't seem like a very good example. I also don't quite understand how this utilises virtual threads effectively, isn't the code still adding the elements of the list one at a time instead of concurrently?
- mikmoila 3y agoOne at a time, not concurrently.
- Tainnor 3y agoso what's the point? we can already write blocking code. The reason why people want to use reactive frameworks is because they don't want to block threads just because some I/O is happening.
- mikmoila 3y agoNima uses virtual threads where blocking call blocks only the current virtual thread but not the underlying carrier-thread, which can run another virtual thread while waiting i/o to complete.
- Tainnor 3y agoBut in this example, the entire code is still blocking because it has to wait for one call of "callRemote" to complete while waiting for the next one to be executed. So I don't get the point. for (int i = 0; i < count; i++) { resp.add(callRemote(client)); }
- canvascritic 3y agoOooh this looks promising. Seeing helidon nima's take on java microservices with virtual threads is certainly a different direction. Way way back, while working with a java microservices codebase, we were stuck with OJ (ObscuraJ, to be honest I'm not sure if it was publicly available or internal, was so many years ago) and that was pure hell. The configuration overhead, especially the cumbersome dynamic routing setup, and layers upon layers of indirection and dependency injection was a headache. níma's approach piques my interest, albeit with a bit of caution, will need to dig into the source more
- rubicon33 3y agoI'll take Scala + Akka over this. Underrated multithreading framework to say the least.
- mikmoila 3y agoOf course, this is not fully comparable to Akka, but you might find this interesting: https://github.com/ebarlas/game-of-life-csp https://github.com/ebarlas/game-of-life-csp
- manicennui 3y agoWhat problem does this solve?
- cowsandmilk 3y agoTaking advantage of a new Java feature for pretty much what the feature is designed for.
- manicennui 3y agoWas an entire framework needed for that? What are the chances that none of the current solutions will add support for this?
- xwowsersx 3y agoI clicked on "see the code" and got: "404 - page not found. The main branch of helidon does not contain the path nima."
- ElectricalUnion 3y agoYep and it says > The technology preview is now available with Helidon 4.0.0-ALPHA5. We will continue releasing previews as the development evolves. and in the default branch `helidon-3.x` there's no `nima` path too, same for a `helidon-4.x` branch.
- deleted 3y ago[deleted]
- whartung 3y agoNot being well versed in the capabilities of the virtual threads. However, both the Servlet and the JAX-RS models are "thread agnostic" in that while we "know" we're running on a thread, the API doesn't expose it directly. So, if something like Tomcat "simply" switch its internal threading model from the current model to the virtual model, would the applications know any different? Could you drag and drop a JAX-RS service or a Java Servlet into a container running on virtual threads, or would rapidly run into some leaky wall? Seems like a virtual thread model of Tomcat would be quite useful in some scenarios.
- doctorpangloss 3y agoIn order to use those things, you have to write annotations. With Nima, you just write the code to do the thing. It's a huge difference. If you have the wisdom to see how toxic annotation-driven programming in Java is, you will like Nima. Helidon Nima is more comparable to building services in golang. It's more like Vert.x but with a serial API.
- Tainnor 3y agoThere are ways of writing Spring without annotations (or XML config): https://blog.frankel.ch/annotation-free-spring/ https://blog.frankel.ch/annotation-free-spring/ Granted, they may not be used much, but if you have an existing application it's probably easier to migrate away from the annotations than to switch to a different framework altogether.
- mongol 3y agoServlets existed before annotations, so no, you are wrong.
- antonhag 3y agoCounter-example: https://javalin.io/ https://javalin.io/ uses Servlets, and seems to be doing quite fine without annotations.
- kimi 3y agoIt definitely would. I - for one - won't be rewriting our 20+ year old servlet app in anything else but servlets, because it has proven to be an exceptionally stable environment. More than virtual threads for Tomcat requests, I'd love cheap, structured threads to be run from within a request, eg to access the database while I'm reading a webservice.