☕ Java Virtual Threads Specification

Javi Hache — Wed, 02 Feb 2022 19:49:38 +0000

I recently found out this interesting Java specification - The Java Virtual Threads

On of the biggest concerns of threads implementation in Java is that they user a real OS threads whenever we use them in our applications.

OS threads are limited and expensive if you don't manage them well. When building a high concurrence software you will need to create and manage a logic to reuse threads as much as possible, usually using thread pools.

The theory is simple: your application should get one available thread of the pool when it needs it and return it once it finishes its job.

But in practice, well.. The thread pools end up being shared between several modules with different responsibilities. That code starts loosing cohesion and it's more difficult to maintain. And at the end one thread cannot be identified with a single transaction because it will be in charge of very different functionalities during its lifetime.

To mitigate this problem, the Java team has created the Virtual Threads. Java will be in charge behing the curtains to asign and liberate OS resources while you will have the possibility to represent single-resposibility transactions with separated Virtual Threads. No more headaches about optimizing the pool (intially) and no more spaguetti code because of that.

Another great things of this new Thread implementation is that is been integrated into Thread API. That way it won't require a big learning curve or it shouldn't have very big side effects if you would like to migrate your code:

// Virtual thread creation using Thread Builder interface
Thread thread = Thread.ofVirtual().name("virtual_thread_1").unstarted(runnable)

// Virtual thread factory
ThreadFactory factory = Thread.ofVirtual().factory();

It looks promising, but I'm expecting to try it out as soon as possible to check the potential of this thread implementation. Let's keep an eye on it!

If you liked this article, feel free to follow me on twitter and check out my personal blog. Thank you! 😁

🐵 Monkey Patches

Javi Hache — Sat, 29 Jan 2022 12:12:23 +0000

Do you know what Monkey Patches are? 🐒

You have probably seen them or even implemented a Monkey Patch before, so let’s delve into details to know more about this way of introducing hotfixes or patches in our code.

A Monkey Patch is an expression used for such changes that are made during runtime to functionalities that are already defined in our code or in external libraries/components.

This is usually done to modify the logic of your own functionality for some corner cases (example written in Javascript):

// Create a class with a defined behaviour
class Monkey {
  constructor(name) {
    this.name = name;
  }

  sayMyName() {
    console.log(this.name);
  }
}

// Create a couple of Monkey instances
let monkeyAndrew = new Monkey("Andrew");
let monkeyRyan = new Monkey("Ryan");

// Monkey Patch the method "sayMyName" for the instance monkeyAndrew
monkeyAndrew.sayMyName = () => {
  console.log(monkeyAndrew.name + " I");
};

// Call to the method "sayMyName"
monkeyAndrew.sayMyName();
monkeyRyan.sayMyName();

This will return the following output:

Andrew I
Ryan

As you can see, we applied a Monkey Patch to the instance monkeyAndrew of our Monkey class. That way, this change of behaviour was only applied to that object and not to the rest of Monkey objects.

Monkey patches can also be applied to external libraries or components if the language allows such modifications (example written in Python):

>>> import math

# Print PI
>>> math.pi
3.141592653589793

# Monkey patch PI and print it
>>> math.pi = 3.1
>>> math.pi
3.1

This practice can be useful if there is a specific case where you need to change the default behaviour. However, I think is not very recommendable. Introducing a Monkey Patch creates an unexpected logic and it can make error handling and identification much more difficult than it should be.

I see the point of applying Monkey Patches in unit testing. When we are creating stubs we are just basically faking the real call to the method with the result that we need. In any other case, if it’s possible is better to extend the class or the module by inheritance or to wrap them adding the functionality you need.

If you liked this article, please follow me on twitter https://twitter.com/javihache_dev and check out my personal blog https://javihache.dev/

DEV Community: Javi Hache

☕ Java Virtual Threads Specification

🐵 Monkey Patches