Project Loom: Revolution in Java Concurrency or Obscure Implementation Detail?

What is the focus of your work these days?

I'm the CTO at DevSkiller. It's a company that specializes in recruiting, screening and managing talents in the tech industry. Our tagline is that we would test real skills as opposed to making sure you can invert a binary tree or do all sorts of algorithmic or very artificial questions, as many big companies are known for. How many balls you can fit into a jumbo jet and so on. We are on the opposite side of that spectrum. We are delivering a platform where candidates who wish to be hired in some nice company are actually doing real programming assignments with code repository with unit and integration tests. And our system makes sure that the homework of the assignment was correct. My role in the company as a CTO is two ways. It's a small company, I'm still doing a lot of development and a lot of code reviews and a lot of making design decisions plus recruiting on our own, dogfooding our own platform and trying to get the ball rolling, so to speak. I still love programming and I try to spend as much time as I can doing software development. I actually put slots in my calendar saying: “Here I'm doing software development, don't put any events here”. That's what I do on a daily basis.

What is the motivation for your talk?

I will be talking about Project Loom, which is not yet available. It's something that will be published with Java. We don't really know. Hopefully within a year or so. It's a project that allows us developers to write concurrent code in a much, much different way, in a much simpler way. Going into details, it will allow us to create millions of threads on the Java platform, which is right now absolutely impossible. This is somewhat similar to, for example, coroutines or goroutines that you can find in Kotlin and Go, respectively. It's built into the actual virtual machine, it's very performant, and this will enable developers as you and me to write very scalable code without worrying that much about memory consumption, without worrying about pulling threads and without fine tuning all this stuff. Hopefully, the reason I'm really excited about this talk is that it will enable developers and library designers to write concurrent code in a much simpler manner and to avoid unnecessary obstructions of pulling threads and paying attention to how much memory you consume. Because idle threats do not really do anything, they are just sitting there consuming memory. This is the main target of this project, and that's why I'm excited about.

How would you describe the persona and level of your target audience?

This is quite interesting because the way we are taught concurrency, in like, let's say, universities or when we are juniors, it's actually very similar to what product Loom offers. Because once you start off, you are taught that you can create a new thread per connection or new thread per request or whatever. And then after you gain some experience you are being taught that this is actually a very poor idea. That once you become a mid-level developer or definitely a senior, you know that creating threads over and over again is a poor idea. And now Project Loom says that what you can actually do that, this is actually a good pattern. We should definitely start with senior developers and architects who can now build solutions in a much more different way. However, if you go back to your team and describe this feature, then your junior developers will actually realize: hey, this is very simple. This is what we were taught in chapter one of concurrency. And that's saying you can forget about all the other chapters. It's just like, this will simplify things greatly.

What would you these personas to walk away with after watching your presentation?

Two takeaways, I would say. First of all, I would like people to get really excited because the project Loom may make your concurrent code much, much more readable, much easier to maintain, because you no longer have to deal with these low level details, pooling threads, making sure your queues are long enough. Tuning, monitoring, and so on. You just create treads as if it was a very native, very low footprint abstraction, which is not the case right now. The first takeaway is that this may revolutionize the way you work with concurrent code. That's why I'm excited about it. On the other hand, we can already see that even though the feature wasn't yet released, you have to be aware of the shortcomings. For example, now the garbage collector has to do much more work because the virtual threads that you can create in millions are actually subject to garbage collection, which means you will have a much harder time fine tuning garbage collectors. There's always a tradeoff. And also, there are a few other disadvantages or limitations of Project Loom that you must be aware of. Otherwise, you will just shoot yourself in the foot. There's no free lunch. I want people to get the best idea, what they can get and what are the best use cases for this new project and whether they should use it from day one, the moment it's released. Or maybe it's just a very specialized tool that they should never really look at because it's a matter of framework developers.