Lambdas are interesting structures. What are they exactly? And why can’t we use non-final local variables in lambda bodies?

Welcome back to the Java-unconfusing series! It’s our safe place to take a look at simple pieces of Java code that don’t always behave exactly as we expect. We look under the hood in order to understand why Java does what it does, so we are never confused again.

Context

Years ago, when we were only starting to use the Streams API in Java, it took some time to switch the mindset and properly use the new approach.

For example, in our lambda, we might have tried modifying a variable defined outside the lambda body, which wasn’t possible. But why?

What are lambdas

Suppose we have a method that accepts a Supplier<Object>:

private static void lambdaFun(Supplier<Object> s) {}

Supplier is one of the functional interfaces. Functional interface is an interface that has one unimplemented method. In this case, it’s a get method, which doesn’t accept any arguments and returns an Object.

When we are writing a lambda, we are essentially writing an implementation of the specific functional interface expected in the context. So, the lambda like () -> 1, when provided to our lambdaFun method, is considered as an implementation of Supplier<Object>, because that’s what lambdaFun expects.

Depending on expected type, () -> 1 can be a Supplier<Integer> or even a custom type that we define ourselves. Everything depends on the context.

Annoying lambda use-case

Let’s take a look at this code:

public static void test(int x) {
    int y = 1;
    lambdaFun(() -> {
        y++;
        return x + y;
    });
}

In this case, the compiler will give us the following error: Variable used in lambda expression should be final or effectively final. What does that effectively final even mean?

What is “effectively final”

The Java compiler does a lot of smart things during compilation. It can analyse the use of variables in certain use-cases to determine if they are constant. The variable might not even be marked as final. If it’s defined within a method body, then nothing from outside can modify this variable. Then compiler only needs to check if it’s modified anywhere inside, and if it’s not, the compiler can safely conclude that the variable is effectively final, in other words a constant value.

Why is that a problem for lambdas

Lambdas don’t allow the use of any variables from outside the lambda body if those variables are not “final or effectively final”. It means they can use variables read-only. Why is that?

Remember, when we write a lambda body, we’re implementing a functional interface? So, in our Supplier case, we’re saying: this is the body of the get method of that Supplier interface implementation that is magically created “in the air”.

Let me explain.

When we compile our code, under the hood a new separate method is created. Say we have this code:

public static void test(int x) {
    lambdaFun(() -> x);
}

The () -> x becomes a method body, and in the bytecode this becomes a separate method named lambda$test$0, generated by the compiler, we can see it in the bytecode:

private static java.lang.Object lambda$test$0(int);
descriptor: (I)Ljava/lang/Object;
flags: (0x100a) ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC
Code:
  stack=1, locals=1, args_size=1
     0: iload_0
     1: invokestatic  #28                 // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
     4: areturn
  LineNumberTable:
    line 7: 0
  LocalVariableTable:
    Start  Length  Slot  Name   Signature
        0       5     0     x   I

The synthetic class that actually implements the Supplier interface and uses this method as implementation is generated later, at runtime. And then the actual instance is created. It happens only in the case when the lambda is actually hit, saving up resources when it’s not.

So, why can’t we normally use outer variables in our lambdas? Simply, because internally lambdas are little methods. Any local variable that they can access, is passed to them (captured) as a method argument. Inside a lambda body, we are viewing a copied value and not an actual variable.

Still, why so final?

It’s easy to see why the local variable defined outside can’t be modified inside the lambda body. But why does it have to be final, in a sense that even after a lambda definition or even execution it can’t be modified?

Let’s imagine this limitation doesn’t exist.

We might want to define a lambda, then try and modify a variable that it uses. The variable value is actually captured at the moment when lambda is executed, so all changes between definition and execution should be taken into account. After execution, no changes are visible to lambda, since it has already entered its own stack with its own variable copy.

This all might look really confusing to a developer. The syntax makes us think that the values are captured at lambda definition, but that’s not true.

We also need to prevent an expectation, that the changes to a variable after lambda execution are visible in the lambda body. They can’t be.

It becomes especially important in a multithreaded environment. We might want to execute a lambda in a new Thread, and modify the variable at the moment that looks to us like “after the lambda execution”. But can we be so sure? Did our new Thread already start and execute our lambda when we modified the variable? Which value will actually be captured, the old one, or the amended one?

Given all of the above, compiler is protecting us from confusions and wrong expectations.

What about fields?

You might have noticed that there is no problem in reading and modifying the fields from our lambdas. Unlike a local variable, which exists with a certain state in a specific method frame, the field is visible to all class members, in all the methods of the class, independent of any frame states. As we remember, lambda body becomes a separate method under the hood. If the field is used in the lambda body, it is not captured as an argument to that method. Instead, the method can read and overwrite that field directly, just as any normal method can do.

That is easy, when the field and the method are located in the same class. Perhaps, we would like to use a reference to an external method in our lambda instead of generating one in the bytecode? For example, like this:

Stream.of(1, 2, 3).forEach(System.out::println);

Then indeed no new method is created at compile time, and instead we will have an existing method System.out.println() as our functional interface implementation. However, the syntax wouldn’t allow us to pass any fields to the method reference, which the external method might not even be able to access.

Let’s play

Digging through JLS (the Java Language Specification), I stumbled upon a couple of interesting examples of lambda bodies using local variables.

Let’s have a look.

#1

void m1(int x) {
    int y = 1;
    lambdaFun(() -> x + y);
}

In this example, both x and y are “effectively final”. They are defined within the m1 method (guaranteed to not be modified from outside). x gets a value when the method m1 is called, and it’s never modified afterward, y is also initialized only once.

#2

What about this one?

void m2(int x) {
    int y;
    y = 1;
    lambdaFun(() -> x + y);
}

y is only initialized once, so it’s still effectively final. We’re good.

#3

void m3(int x) {
    int y;
    if (x == 2) y = 1;
    lambdaFun(() -> x + y);
}

Variable y is initialized conditionally, in proper terms they call it not definitely assigned. We can’t use an uninitialized variable because then there’s no value for our lambda to capture (to feed it as an argument into a method created under the hood). That won’t compile!

#4

void m4(int x) {
    int y;
    if (x == 2) y = 1; else y = 2;
    lambdaFun(() -> x + y);
}

We do have a conditional assignment to y, but it’s guaranteed that in any condition there will be something (else covers all possible cases). There will be for sure some value that’s going to be assigned to it once and only once. We’re good!

#5

void m5(int x) {
    int y;
    if (x == 2) y = 1;
    y = 2;
    lambdaFun(() -> x + y);
}

Here we have a possibility that y gets reassigned, meaning that y is not effectively final. Won’t compile!

#6

void m6(int x) {
    lambdaFun(() -> x + 1);
    x++;
}

Even though x is modified after our lambda definition, it still means that x is not effectively final. Won’t compile!

#7

void m7(int x) {
    lambdaFun(() -> x = 1);
}

Won’t compile either: x is attempted to be modified within lambda body.

#8

void m8() {
    int y;
    lambdaFun(() -> y = 1);
}

What about this one? y is not having any value, so it can’t be captured by lambda. And then, we are trying to modify it within the lambda body. None of that is going to work…

#9

void m9(String[] arr) {
    for (String s : arr) {
        lambdaFun(() -> s);
    }
}

Here, on each iteration we are creating new instance of String. Each of these instances is definitely assigned a value, and it is guaranteed to happen only once. Everything is alright!

#10

void m10(String[] arr) {
    for (int i = 0; i < arr.length; i++) {
        lambdaFun(() -> arr[i]);
    }
}

Unlike in the previous example, here we are reusing the same variable i and modifying its value by incrementing it on each iteration. Variable i is not effectively final, so this won’t work.

#11

void m11(int x) {
    int y = 1;
    if (x == 2) y = 1;
    lambdaFun(() -> x + y);
}

I know, it looks like we are not changing the value of y here, yet the value is getting overwritten, meaning that the variable is not effectively final. This won’t compile!

Conclusion

Lambdas are interesting structures. But we can get a feeling of how they are going to behave simply by realizing one thing: lambda body is, or becomes, a separate method. Any local variables that we use in the lambda body are captured as method arguments, so we can access only the copies of the values. Our compiler protects us, so we can’t use non-final local variables in our lambdas.

Hope this was educative and fun! Here are the related docs.

If you liked this little post, take a look at the previous posts from the series:

• Unreachable statements
• Widening
• Expressions
• Concatenation operator
• Increment

Do you think Java consistently rejects all unreachable code? Well…

Welcome back to the Java-unconfusing series! Usually here we take a look at the pieces of code which may look really innocent, but not work as we expect. Or not compile at all. It’s good to dive into the reasons why it is a certain way, so we can learn more about Java ideology and design decisions. Let’s get unconfused together!

Let’s talk about unreachable statements

There are a number of different use-cases when the code is considered unreachable. The compiler doesn’t accept this code. Examples include statements that follow break or return, or infinite while(true) loops, for example. We have all seen these.

Let’s take a look at this particular example:

int a = 0;
while (false) {
    a = 10;
}

The compiler tells us that the loop condition is always false, and that makes the loop body unreachable. Makes sense that it doesn’t compile.

What about the following example?

int a = 0;
if (false) {
    a = 10;
}

The condition is always false, which means that the body can never be executed. However, this piece of code is accepted by the compiler! Technically, the Java compiler doesn’t even consider it ‘unreachable’.

Why is it so?

This choice has been made consciously. When the condition is a constant false value, the compiler doesn’t add the contents of the entire conditional block to the resulting set of the bytecode instructions. This allows developers to define flags such as:

static final boolean FEATURE = false;

And then use it in a condition.

Later on, it’s easy to change the value of the FEATURE flag to true, but there’s one important detail to it. If the flag itself and the conditional block are located in different classes, it’s important to recompile the class containing the condition, since the whole new set of instructions might be added to the bytecode.

When is it so?

Coming back to our while (false) example, such behaviour is only happening when the condition is a constant false value.

So, this would work without any issue:

int a = 0;
int b = 10;
while (b + b < 10) {
    a = 1;
}

While this wouldn’t compile:

int a = 0;
final int b = 10;
while (b + b < 10) {
    a = 1;
}

The reason is that the compiler is performing optimisation called ‘constant folding’. All known (constant) values can be used in order to pre-calculate anything where possible. If the values are constant, the assumptions can be safely made, but not otherwise.

So, in the example above, the compiler knows that our actual condition is 10 + 10 < 10, and it is false, and it can’t be changed from anywhere else in the code. So it is safe to conclude that the code is invalid.

Crazy thoughts

Curious minds might wonder: if if (false) {} block contents are not placed into the bytecode at all, does it mean that the compilation of that block is skipped entirely? So any nonsense inside that block would not result in a compile error? The answer is no. The compiler still diligently does its work and reports any compile errors within that block.

Hope this was educative and fun! Here are the related docs.

If you liked this little post, take a look at the previous posts from the series:

• Widening
• Expressions
• Concatenation operator
• Increment

Welcome to the fourth episode of our Java-unconfusing series, where we look at some basic concepts in Java (in fact, it applies to many other languages too) that result in confusing outcomes in certain cases. When that happens, most likely the code quality could do with some improvements.
In any case, it’s good to know what we can expect from Java and never be confused by it.

Today, I would like to talk about ‘widening’…

Example

Assume we have two short values and we’d like to calculate their sum. It would make sense to write the following piece of code:

short a = 10000 ;
short b = 20000 ;
short c = a + b;

However, this code does not compile. Java compiler considers the result of this expression as integer value instead of short.

We could, of course, cast the result to short, successfully compile it and get the expected result:

short a = 10000 ;
short b = 20000 ;
short c = (short)(a + b); // c == 30000

Why do we have to cast?

If we look at the bytecode of the previous example, we will find a following piece:

0: sipush 10000
3: istore_1
4: sipush 20000
7: istore_2
8: iload_1
9: iload_2
10: iadd
11: i2s
12: istore_3

It starts with sipush, and the function of this bytecode operation is literally to push a short onto the stack as an integer value.

The following operation is istore_1, and it already tells us that it stores variable a as integer. Same happens for b.

All the following operations are simply integer manipulations, including iadd which sums two integer values.

At the end, because we performed the casting, we find i2s (integer to short) casting operation, but still the final result that is stored in the local variables is again an integer value.

But why?

What we have observed is called ‘widening primitive conversion’. The short value, which takes two bytes, is put in a bigger ‘box’ of 4 bytes, which is an integer type.

Why is this happening in this case? There are simply no bytecode instructions which would allow to perform operations directly on short values, so they are converted to integers.

OMG, what’s that though?

If we write our original code without any casting, but make our variables final, there is no problem compiling that!

final short a = 10000 ;
final short b = 20000 ;
short c = a + b;

This behaviour is easy to explain. Let’s take a look at the relevant piece of bytecode:

 0: sipush 10000
 3: istore_1
 4: sipush 20000
 7: istore_2
 8: sipush 30000
11: istore_3

As we can see, all values including the resulting sum are considered as constant values. The sum is calculated during compilation and placed directly into the bytecode. This is one of the compiler optimizations called ‘constant folding’.

In this case, compiler could calculate the sum and see that the resulting value 30000 indeed fits into 2 bytes to be of a short type.

If we do a slight change to our code so the sum wouldn’t fit into a short type, the compiler immediately starts to complain:

final short a = 20000 ;
final short b = 20000 ;
short c = a + b; // won’t compile, because 40000 doesn’t fit in 2 bytes

Note: if we had the same code, but all our values were integer, and the sum didn’t fit into an integer, we would have gotten a warning, but compiler would have accepted it anyway.

Cases of widening

There are different use-cases of widening primitive conversion. Often it is happening when one of the values in a single operation is of a wider type,
so the other value is widened to match.

Also, short, byte, char and boolean values are always converted to int under the hood. There is simply no means of dealing with these types on the bytecode level.

Short doesn’t exist?

It’s a good question.

We have seen from the above examples that short is saved into the local variables as an integer value. So is it just a Java code sugar?

Using the following code, we can try and figure out, what is the type of our primitive variable:

short a = 20000;
System.out.println(((Object)a).getClass().getName());

The code above outputs java.lang.Short. So did we get something wrong?

If we look in the bytecode, we will find our answers:

0: sipush 20000
3: istore_1
4: getstatic #7 // Field java/lang/System.out:Ljava/io/PrintStream;
7: iload_1
8: invokestatic #13 // Method java/lang/Short.valueOf:(S)Ljava/lang/Short;
11: invokevirtual #19 // Method java/lang/Object.getClass:()Ljava/lang/Class;
14: invokevirtual #23 // Method java/lang/Class.getName:()Ljava/lang/String;
17: invokevirtual #29 // Method java/io/PrintStream.println:(Ljava/lang/String;)V

What is happening here is that we are saving our value as an integer variable. Then we load it onto the stack and use Short::valueOf method to make it short again. Compiler knows, that it’s a short, because we specified it in our code. So it makes sure that our short variables behave as they should. But in the end…

short is a lie :)

(yes, and byte as well)

Hope this was educative and fun!

Today I’m going to show you a simple numeric expression…

Example

Let’s take a look at the following line:

System.out.println(1 / 2 + 3.0 * 1 / 2);

What do you think is the output?

What happened

There is nothing interesting happening in the bytecode:

0: getstatic     #7  // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc2_w        #13 // double 1.5d
6: invokevirtual #15 // Method java/io/PrintStream.println:(D)V
9: return

The result of the expression is a constant value 1.5d, which means that the expression has been fully pre-calculated (optimised) during compilation.

But how come it’s 1.5?

We do expect that the type of the result is double, since we have an explicitly double value 3.0 in the expression.

But let’s start with integers

If instead of 3.0 we had just 3, we could have expected a result to be an integer.

So, for integers, we’d have: 1 / 2 + 3 * 1 / 2 = 1.

Explanation:
1 / 2 results in 0, because the rounding to an integer value happens by simply chopping off the remainder, even when it’s 0.5 or greater.
So, the expression becomes: 0 + 3 * 1 / 2.
Next operation is 3 * 1, because multiplication dominates over addition. We will end up with 3 / 2, which normally equals 1.5, but since it’s an integer value, it becomes 1.

Now let’s mix in some doubles

Original expression, for reference: 1 / 2 + 3.0 * 1 / 2.
This will result in 1.5.

Explanation:
If we follow the appropriate priorities, the first operation we encounter is the leftmost 1 / 2. There are no doubles participating in this operation, so the result is an integer value. Normally, 1 / 2 = 0.5, but with integers it results into 0.

Now we have: 0 + 3.0 * 1 / 2.
The next operation by priority is 3.0 * 1, which will result in a double value 3.0.
Our expression transforms into 0 + 3.0 / 2.
Next operation is division: 3.0 / 2 = 1.5, the result is double, since we do have a double participant here.
The final result is 0 + 1.5 = 1.5.

Lessons learned

In such confusing expressions with mixed types, it’s important to keep track of the two things:

• What is the next binary operation by priority? Expressions inside the parentheses dominate over the ones outside, the more nested they are, the higher the priority. Multiplication and division dominate over addition and subtraction.
• What are the types of the participants? Double type dominates over integer. String dominates over them all :)

Remembering that, it’s easy to perform one binary operation at a time (in your head) and keep track of the type and resulting value.

Hope this was educative and fun!

If you liked this one, take a look at the previous posts from the series:

• Increment
• String operator +

Welcome to the second episode of this little Java-unconfusing series. Today I would like to talk briefly about String concatenation operator +.

First, let me share some interesting use-case, then we will take a look under the hood to understand what happened.

Example

Let’s take a look at the following piece of code:

System.out.println(1 + 5 + "text" + 5 + 1);

What do you think this code will output?

What happened

If we look at the bytecode, we will see a very boring piece:

0: getstatic     #7    // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc           #13   // String 6text51
5: invokevirtual #15   // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return

We see that the String evaluation doesn't happen at runtime, it has happened at compile time. The whole expression got optimized away, so we're dealing with a constant value: 6text51.

But how did this value come to be?

Going from left to right, only two first operands are taken into account at a time. If none of them is String, and the numeric operation can be performed, it is performed. If any of the two is String, the other operand will also be converted to a String, and they will be concatenated.

So, in our example, first operation is 1 + 5, which can be evaluated as 6. Next, we will have 6 + "text", which will result in concatenated String "6text". Afterwards, all the operations will be resulting in String concatenation, bringing us to the final result: "6text51".

Let's try something out

Let's try out something strange. As mentioned, the evaluation happens at compile time. What if we force it to happen at the runtime?

For example, we can create a situation where the exact type of some value is not known at compile time.

It looks ugly, but bear with me:

boolean cond = args[0].contains("true");
var unknown = cond ? 1 : "text";
System.out.println(unknown + "text" + 5 + 1);

Based on what we discussed before, we know that here it doesn’t matter what is the type of the unknown variable, because the second operand is String, so the first two operands will be concatenated.

This is the relevant piece of bytecode:

0: aload_0
1: iconst_0
2: aaload
3: ldc           #7       // String true
5: invokevirtual #9       // Method java/lang/String.contains:(Ljava/lang/CharSequence;)Z
8: istore_1
9: iload_1
10: ifeq          20
13: iconst_1              // this is just a constant integer value, but in the next line we're going to wrap it into an object
14: invokestatic  #15     // Method java/lang/Integer.valueOf:(I)Ljava/lang/Integer;
17: goto          22
20: ldc           #21     // String text
22: astore_2              // here we're saving a reference to some object, 
                          // either a String or Integer, depending what's on our operand stack at the moment
23: getstatic     #23     // Field java/lang/System.out:Ljava/io/PrintStream;
26: aload_2               // loading our mystery object onto the stack again
                          // the next operation will call a String.valueOf method which will accept the
                          // mystery Object as an argument and convert it to a String
27: invokestatic  #29     // Method java/lang/String.valueOf:(Ljava/lang/Object;)Ljava/lang/String;
                          // finally, the actual operation will result in a String concatenation
30: invokedynamic #32,  0 // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
35: invokevirtual #36     // Method java/io/PrintStream.println:(Ljava/lang/String;)V

To summarize the above bytecode: we don't know at compile time, what’s the type of unknown variable. However, no matter what it is, it's going to be ultimately converted to a String, because the next operand in our expression is String, so they will be concatenated in any case.

Now the interesting part. What if we make the second operand non-String?

boolean cond = args[0].contains("true");
var unknown = cond ? 1 : "text";
System.out.println(unknown + 1 + "text" + 5 + 1);

Now, the compiler knows that it's not necessarily a String concatenation. It can be something else depending on the type, but the type of the first operand is unknown... What would you do if you were a compiler?

The correct answer is: complain :) This simply won't compile.

Lessons learned

String concatenation is a very interesting operation, because it leverages a lot of optimizations both at compile time and at runtime.

Today we saw how the compile time evaluation happens: two operands at a time, from left to right. And if you're giving your compiler hard time deciding what operation it should perform, it will shout at you.

Hope this was fun and educative! See you in the next one!

P.S.: If you liked this one, chances are you’d also like the one about increments.

Sometimes the code that seems really clear can turn out to be quite deceiving, even in some really basic concepts. In these situations, it’s good to question whether that code doesn’t smell…

Either way, it’s interesting to know about the cases where Java can be confusing. So I decided to make the series of little Java surprises.

Traditionally, I will be peeking under the hood, so we can be efficiently unconfused :)

Example

Let’s take a look at the following piece of code:

int a = 0;
a = a++;

What is the value of a as result? Did you get it right? It’s 0.

What happened?

In the bytecode, increment will be performed using the iinc bytecode instruction. The value that we want to increment does not need to be placed onto the operand stack, because iinc modifies the variable directly in the array of local variables.

Now, still, the post-increment (a++) should work as follows: first use the unmodified value, then increment it.

Does it mean that it will:

• assign a = a (a is still 0, redundant, but ok)
• increment variable a directly (a should become 1?)

Not exactly! Let’s take a look at the bytecode, shall we?

This is the relevant piece:

0: iconst_0      // load constant value 0 onto the stack
1: istore_1      // save the value from the stack in slot 1
2: iload_1       // load from slot 1 to the stack (value = 0)
3: iinc     1, 1 // increment the variable in slot 1, it becomes 1 (not the value on the stack, it's still 0!!)
6: istore_1      // save the value from the stack into variable 1 (override variable 1, so it becomes 0)

To summarise:

• the value was used in the expression before it was incremented (0)
• the variable was indeed modified afterward (1)
• but then we override it with the result of our expression (0)

Ok, another example:

int a = 0;
a = a++ + ++a;

What is the value of a? Just take a second to process, result will be at the end :)

Ok, what’s happening:

0: iconst_0        // load 0 onto the stack
1: istore_1        // store it in slot 1 (value 0)
 
// now our expression is processed from left to right:

2: iload_1         // load it back onto the stack (value 0),
                   // means we will use this a = 0 in the first half of expression, 
                   // and any increments of this variable in the next lines
                   // will affect the variable, but not our stack:
3: iinc     1, 1   // post-increment variable in slot 1 (value = 1)
6: iinc     1, 1   // this is part of following pre-increment, same variable (value = 2)
9: iload_1         // load the variable onto the stack (value = 2)
10: iadd           // calculate sum of two top values from the stack (2 + 0 = 2)
11: istore_1       // save the resulting value into variable 1

This time, the result of post-increment in first part of the expression is not ignored. The expression continues after post-increment, so we are not yet saving anything to the final resulting variable, and we do use the incremented variable again in the expression.

As result, a becomes 0 + 2 = 2.

Lessons learned

Unlike post-increment, pre-increment would have modified the value first, and then loaded it onto the stack and used in the expression. So we would have seen a less unexpected result…

However:

• having increment (or decrement) as part of expressions is BAD (makes the code confusing, as you see);
• it is redundant to assign incremented value to itself, because increment modifies the variable directly, so in our example you can do just: a++;.

Hope this was fun and educative! See you in the next one!

It seems like a really smart idea, right? Having the possibility to host many different languages on top of the JVM, which, during compilation, get translated into the standard bytecode format. The JVM doesn’t care what the source language is, as long as the class file is valid.

JVM checks that the format of the class file corresponds to the expected format. Only then will it load and execute the program.

Designing such system is smart; however, it wasn’t designed with this idea in mind. Initially, the JVM was meant to host only one language — Java.

That means that some of the limitations of Java also constrained the JVM in the same way.

Statically vs dynamically typed languages

Java is a statically typed language. What does that mean? In statically typed languages, all code gets checked during compile time in order to verify all the types. If the types are incorrect, the compilation will fail, and we won’t even get to the point of invalid bytecode.

For example, if we have an instance of type String and attempt to invoke a method on this instance that belongs to another type, such as StringBuilder, clearly that won’t be valid. The typing is very strict; even if we were to generate an invalid class file using special tools, the JVM would throw it up before even trying to execute. The advantage of this approach is the short feedback loop and the trust that we have in our code at runtime.

In dynamically typed languages, types might be not specified in the code at all. Only at runtime will we see if the values we’re actually getting correspond to the types we’re expecting. That can lead to many unpredictable situations at runtime.

Because Java is a statically typed language, it also implies that the JVM was designed to host a statically typed language. It’s designed to deal with class files where everything is checked in terms of types before the runtime. One might think, is it impossible to build a dynamically typed language on the JVM then?

As we know, there were a lot of JVM languages emerging, including dynamically typed ones. Here are just a few examples:

The creators of dynamically typed languages faced challenges in circumventing the limitations. Specifically, they had to address method invocation in situations where the type of an instance that owns the method is unknown at compile time.

Possible workarounds

Let’s consider this example:

def absolute(num):
    return num.__abs__()

print(absolute(-1))
print(absolute("a"))

This is a valid piece of Python code. We’re not specifying neither the return type, nor the type of the argument. However, inside the absolute function, we assume, that argument num is numeric, and we call a __abs__ function on it. At runtime, we can call our function with a numeric value, and it will be fine. We can also call it with a str value, and it will fail.

Imagine you’re a language creator, and you want to make this piece of code runnable on the JVM. How would you work around the limitations?

One possible solution is to create a language-specific type that covers all possible types you might have. Under the hood, in the bytecode, you would have something like this:

public static SuperType abs(SuperType num) {
    return num.abs();
}

public static void main(String[] args) {
    SuperType result1 = abs(SuperType.of(-2));
    SuperType result2 = abs(SuperType.of("a"));
}

SuperType becomes your global language-specific type. You accept it as the type of your argument, you return it. In this case, you would need to implement all possible methods that you might want to call on any of your types, and they all should be implemented in your SuperType class. That might be challenging, as it’s hard to know in advance all possible methods you want to have in your types. You’ll also need to consider how to convert Java types into a SuperType, etc.

This is a possible workaround, but it’s quite an ugly one. Other potential solutions involve reflection or additional interpreters, but they come with their own limitations and are often slow.

Still, those who were building the dynamically typed languages on JVM, had to use them. Until…

Introduction of invokedynamic (indy)

invokedynamic is a bytecode instruction introduced to support the dynamically typed languages on JVM. Let’s see some other instructions for method invocation and understand how invokedynamic is different.

In JVM, there are also invokevirtual, invokestatic, invokespecial, and invokeinterface. Let’s take a closer look at two of them that are very commonly used.

Invokevirtual

invokevirtual is used when we would like to invoke a method of some instance. Before using this instruction, we should put a reference to the instance that owns this method on top of the operand stack. Afterwards, we have to put all the arguments on top of the operand stack as well, ensuring they all have the correct types. When we use the invokevirtual, we specify the type where the method is located, the method name, the types of the arguments, and return type:

So, in this case, we put a reference stored in a static field System.out onto the stack. Its type is PrintStream. Afterward, we place the constant String value on top of the stack, which will be the argument that the method accepts. When we use invokevitual, we specify that the method’s name is println, the method is located inside PrintStream, it accepts a single argument of type String, and returns void. It’s not possible to use invokevirtual without this diligent specification of all these details, so for dynamically typed languages it’s not usable.

Invokestatic

invokestatic does a similar job. The only difference is that we’re invoking a static method, so there is no instance that owns it. That means we don’t need to place any reference of the owner instance onto the stack. Still, we have to place all the arguments there:

For theinvokestatic instruction, we also need to specify the type where the method is located, along with the method name and all the types. In this case, the method belongs to theString type, its name is valueOf, and it accepts an int while returning a String.

How is indy different?

As in the previous examples, the invokedynamic instruction also requires you to provide the arguments onto the stack. However, it doesn’t require you to specify either where the method is located or its name. We are only specifying that eventually, we would like to call a method that accepts an int and returns a String. We are also specifying some method name makeConcatWithConstants, but in this case, it’s arbitrary and won’t play any role.

The crucial element is the reference #0, which points to another section in the bytecode called BootstrapMethods. A bootstrap method is a method that makes a decision at runtime about which target method we would like to invoke. This means that at compile time, we don’t even know where that method is located and how it’s called, but the bytecode is still valid!

When the JVM executes the bytecode and encounters the invokedynamic instruction, it invokes the bootstrap method. The bootstrap method performs some logic (which can include generating synthetic code, among other things), and ultimately, it looks up a MethodHandle for the method that needs to be invoked. A MethodHandle is a mechanism, similar to reflection but faster, that provides a direct reference to the method. The JVM then links that target method handle to the specific invokedynamic instruction and invokes the target method.

When the JVM encounters this particular invokedynamic instruction again, if nothing has changed, it directly invokes the linked target method. The method handle lookup doesn’t happen again in this case.

Alright, back to Java

This provides a lot of possibilities for creators of dynamically typed languages, but I promised to talk about Java.

It turns out that invokedynamic is often used by the Java compiler, so there are more and more use-cases where we can find it in the bytecode generated by javac.

Let’s take a look at some of them.

String concatenation

In Java, invokedynamic (indy) is used for some cases of String concatenation. Of course, when we're concatenating constant values, the compiler optimizes the entire concatenation away. However, if we're dealing with non-final variables, we will find invokedynamic in the bytecode.

In the example above, we’re concatenating two String variables. In the bytecode, we place both references to them onto the operand stack. Then, we use indy, where we say that we want to find a target method at runtime, and that method will accept two Strings and return a String.

In the BootstrapMethods section, we use the StringConcatFactory::makeConcatWithConstants method. It accepts many arguments, most are automatically filled in by the JVM. We can also provide some arguments through Method arguments. In this case, we’re providing a “recipe”, which is kind of a template with placeholders for parameters. This way, we provide information to the Bootstrap Method on how exactly we’d like to concatenate the elements.

What does the Bootstrap Method do? This is some of its logic:

It turns out that both unary and binary concatenations can go through a faster implementation than other cases. We have two elements, both being parameters and non-primitive and non-null values, so we lookup a simpleConcat method for them. This method performs basic byte array manipulations, similar to how StringBuilders work.

What did indy give us in this case? The ability to make a decision at runtime: determine which logic is more performant for this use-case and eliminate unnecessary logic at all.

Pattern matching for switch

In the newest Pattern Matching for Switch, we’re also using the invokedynamic! We now have the ability to switch over different types:

Here, we have String and Integer types, and there could be more. We can also use guard conditions, in which case the types might be repeated. But what is happening under the hood?

The task of the target method here is to return an integer. That integer value helps the next instruction to find the location in the bytecode where to jump and execute some block of code. That’s it.

We provide the arguments to the bootstrap method, which is simply a list of all types we’re switching over. For each type, the bootstrap method looks up a method handle for a method that does type checking for that particular type, and these method handles are then combined in a chain and encapsulated into a final MethodHandle. When invoked at runtime, this final MethodHandle executes all the checks for all the types, and depending on these checks, it calculates the integer value to return.

In summary, we have a dynamic decision-making logic that is executed at runtime.

Lambdas

The most exciting part where indy is used in Java is with Lambdas.

When we define a lambda body, we’re essentially implementing a functional interface (an interface with a single abstract method). Indy allows us to have a synthetic class that implements that method with whatever implementation we provide as the lambda body. Then, we can get instances of this implementation whenever needed, and all of this happens at runtime! No extra classes are generated during compilation.

Let’s take a look at this example:

Here, our functional interface is Consumer. We use invokedynamic, specifying that we want the accept method to be implemented with the code from the lambda body.

At runtime, the bootstrap method creates a synthetic class that implements the accept method of Consumer. The target method handle that the bootstrap method gives us back is simply a factory, which returns an instance of this Consumer implementation whenever we hit this invokedynamic instruction. Afterwards, we can provide this instance to the forEach method.

In this case, we specify that we want the accept method to do what System.out::println does, so we simply provide a reference to that method as an argument. Alternatively, we could use a custom block of code. In that case, during compilation, that block of code would be placed in a separate method, and we would provide a reference to that method.

In summary, indy allows us to generate code only in the case when the lambda is actually hit and only once. Moreover, we're not polluting our bytecode with all the extra classes because all of this is taken care of during runtime.

What about AOT?

As we know, AOT compilation doesn’t like any dynamic behavior because all possible invocations should be known ahead of time.

Consider GraalVM native image, for instance. If there’s anything dynamic, such as reflection, we also have to provide a configuration where we specify all the possible methods that could be called through reflection at runtime.

How does the invokedynamic work then?

Well, anything that javac (as well as the Kotlin compiler) places in the bytecode is supported by GraalVM out of the box. These cases are known, and there’s a limited amount of them, so GraalVM simply takes them into account inside the logic of native image creation.

If you’re building a new compiler, you probably want to establish some agreements about such support. If you’re manipulating the bytecode, be careful (and not too creative) when playing with the invokedynamic instruction; otherwise, the produced bytecode might fail inside the native image.

Final words

After playing with invokedynamic for several months… I have finally stopped asking myself ‘why’. Why is it good for Java? What are the benefits?

Indy helps us reduce the complexity of the bytecode. We save space by not polluting our bytecode with all the things that are not even related to our program, such as all the language logic. The logic becomes more and more complicated with the newer versions of Java, so it’s good to have it abstracted away.

The implementation of some language features can improve from version to version, and we don’t even need to change the bytecode (rebuild the project) to benefit from them. We won’t even notice that something has changed, but the program might become more performant.

Believe me, the implementation of language features does change. For pattern matching, I looked at how it worked in the Java 21 Early Access version, and then I looked again when Java 21 was actually released. The implementation was completely different… and yet, the bytecode remained the same.

Can there be any downsides? Of course. The predictability of our program might decrease without us making any changes. Perhaps the previous implementation of String concatenation was less performant but gained performance by taking up more space? By putting more String instances onto the heap? That might be the case, as the previous implementation of String concatenation used StringBuilders, and now it’s different.

Things might change for better or worse, but, of course, all these changes are intended to benefit us in future versions.

Resources

I was heavily relying on this article when I spoke about dynamically typed languages on JVM. Take a look if you’re interested to dig deeper into the topic:

New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine

This small episode related to Java compilation seemed interesting and a bit funny to me, so I’m sharing it here. Hope you enjoy it too 😊

I was working on a (pet) tool for editing class files in the format of Java code. For that, I was using the Procyon decompiler and the Java Compiler API. So, simply, I needed to “translate” the code back and forth, from the JVM bytecode to Java, and then back to the bytecode.

It was also important for me to ensure that I compiled the code using the exact Java version with which it was originally compiled. I used ASM to retrieve the Java version from the class file, so then I could provide it to the compiler.

When I started testing it with some Java code, it went fine with my first (somewhat bigger) example. However, when I started trying out different Java versions, suddenly my method got empty in the final result (bytecode — > decompiled to Java — > compiled to bytecode). I thought that I broke it by using a different Java version, but actually the problem had a completely different origin.

Example Java code that I used for testing:

public class Main {
   public static void main(String[] args) {
       int num = 42;
       String test = "I have " + num + " cows!";
   }
}

When this code is compiled, it utilizes the invokedynamic instruction in the bytecode for this case of String concatenation. Usually, when you view class files in IntelliJ IDEA, they are shown decompiled with Fernflower:

public class Main {
   public Main() {
   }


   public static void main(String[] args) {
       int num = 42;
       String test = "I have " + num + " cows!";
   }
}

Looks good.

In my project, this was decompiled using Procyon and looked slightly differently:

public class Main
{
   public static void main(final String[] args) {
       final int num = 42;
       final String test = "I have " + num + " cows!";
   }
}

And then, if the above Java code is compiled, the Code section in the bytecode for the main method is empty! Decompiled again, it would look like this:

public class Main {
   public Main() {
   }


   public static void main(String[] var0) {
   }
}

I understood that the variables are optimized away because they are not used. So I added a “blackhole” for them, which was represented by System.out::println:

public static void main(String[] args) {
   int num = 42;
   String test = "I have " + num + " cows!";
   System.out.println(test);
}

Eventual result from my project (decompiled again):

public class Main {
   public Main() {
   }


   public static void main(String[] var0) {
       System.out.println("I have 42 cows!");
   }
}

I was like, no invokedynamic? Just a boring constant value? What happened? The thing is, Procyon added the final keyword for my variables, which tells the compiler that they have fully constant values in the end:

final int num = 42;

For the case of String concatenation that involves only constant (final) values, there will be no invokedynamic whatsoever. It will simply be a constant value.

Two different decompilers produce results that are not incorrect, but vary a bit. Procyon was smart enough to analyse the code and figure out that the variables were effectively final, so it marked them as final(I’d argue if it really had to).

To be honest, I had some Google Translate vibes (try translating between two languages back and forth for several times).

It seems, if my tool ever comes to life, it will be fun to use it 😛

This experiment intends to demonstrate the power of the invokedynamic instruction in JVM. This instruction is used for different pieces of Java functionality these days, such as switch statements, lambdas, and many cases of String concatenation.

The idea is that, in the bytecode of our compiled class, invokedynamic points to some specific Bootstrap Method, which at runtime can choose a target method to be invoked. This way, we can have compact bytecode without even knowing, for example, which method concatenates Strings for us. If newer Java versions improve performance or add more alternative methods to choose from, we won’t need to do anything to benefit from them.

Redefining the Bootstrap method

Can we redefine the Bootstrap Method and invoke another target method at runtime? My experiment proves that it’s possible, although clearly, we shouldn’t ever want to do this :). It’s not intended for any real-life situations.

The case of String concatenation

As I mentioned, String concatenation is widely leveraged by invokedynamic. Depending on the number of parts to concatenate and their types, the behaviour can differ.

Let’s consider the following example:

public class Test {
    public static void main(String[] args) {
        String test = "something";
        System.out.println("something lalala something else " + test);
    }
}

When we compile this class and check the bytecode, we see the invokedynamic instruction in the Code section of our main method:

...

0: ldc           #7       // String something
2: astore_1
3: getstatic     #9       // Field java/lang/System.out:Ljava/io/PrintStream;
6: aload_1
7: invokedynamic #15,  0  // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;)Ljava/lang/String;
12: invokevirtual #19     // Method java/io/PrintStream.println:(Ljava/lang/String;)V
15: return

...

BootstrapMethods:
  0: #36 REF_invokeStatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #34 something lalala something else \u0001
...

In the BootstrapMethods section, we see which method exactly is responsible for determining the dynamic behaviour: StringConcatFactory.makeConcatWithConstants.

Without going into too much detail, the functionality triggered by this method involves checking some parameters and their types. It then looks up the MethodHandle of a specific method and wraps it in a CallSite instance. Then, the found method is invoked via the JVM mechanisms.

StringConcatFactory is all about this bootstrapping logic. Most of the target methods it finds in the end are in StringConcatHelper class.

For example, this is the body of method simpleConcat, which will be called for our specific use case (for concatenating a constant String and a variable of non-primitive type):

    private static MethodHandle simpleConcat() {
        MethodHandle mh = SIMPLE_CONCAT;
        if (mh == null) {
            MethodHandle simpleConcat = JLA.stringConcatHelper("simpleConcat",
                    methodType(String.class, Object.class, Object.class));
            SIMPLE_CONCAT = mh = simpleConcat.rebind();
        }
        return mh;
    }

It looks up the method StringConcatHelper::simpleConcat, which accepts two Object arguments, and returns a String. At the moment when the target method is invoked, there will be two Objects sitting on top of our operand stack. We can also cheat a bit because we know that, in our case, these Objects will be Strings.

How do we use this knowledge?

Can we override the body of this method and look up some other MethodHandle? Of course we can! But we should keep in mind that the signatures should match. Or, if they don’t match, we can manually inject some extra arguments.

I thought it would be fun to look up the String::replaceAll method. Unlike the original method that is called, it’s not a static method. Both of our Strings will come in as method arguments for the original method. However, for replaceAll, the first String will be the owner Object reference, and the second one will come in as the first method argument (replace what). We are missing the second argument (replacement), but we can inject this one ourselves.

Looking up some other MethodHandle

This code does the job:

MethodHandles.Lookup lookup = MethodHandles.lookup();
MethodType mt = MethodType.methodType(String.class, String.class, String.class);
MethodHandle mh = lookup.findVirtual(String.class, "replaceAll", mt);
return MethodHandles.insertArguments(mh, 2, "^_^");

We can test what this does with a simple example:

mh.invoke("rrrrr aaa fffff", "aaa");

As a result, it will replace all “aaa” in “rrrrr aaa fffff” with cute smileys “^_^” , so we will end up with “rrrrr ^_^ fffff”.

The bytecode

To override the method in StringConcatFactory class, we will need to manipulate the bytecode. The above code that we want to use as the new body for simpleConcat method results in this bytecode:

0: invokestatic  #35  // Method java/lang/invoke/MethodHandles.lookup:()Ljava/lang/invoke/MethodHandles$Lookup;
3: astore_0
4: ldc           #41  // class java/lang/String
6: ldc           #41  // class java/lang/String
8: iconst_1
9: anewarray     #43  // class java/lang/Class
12: dup
13: iconst_0
14: ldc           #41 // class java/lang/String
16: aastore
17: invokestatic  #45 // Method java/lang/invoke/MethodType.methodType:(Ljava/lang/Class;Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType;
20: astore_1
21: aload_0
22: ldc           #41 // class java/lang/String
24: ldc           #51 // String replaceAll
26: aload_1
27: invokevirtual #53 // Method java/lang/invoke/MethodHandles$Lookup.findVirtual:(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MethodHandle;
30: astore_2
31: aload_2
32: iconst_2
33: iconst_1
34: anewarray     #2  // class java/lang/Object
37: dup
38: iconst_0
39: ldc           #59 // String  ^_^
41: aastore
42: invokestatic  #61 // Method java/lang/invoke/MethodHandles.insertArguments:(Ljava/lang/invoke/MethodHandle;I[Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;
45: areturn
46: astore_0
47: aconst_null
48: areturn

The plan

To achieve my goal, I need to:

• Create a Java Agent that redefines the Bootstrap Method. When running a test program, we can simply specify a javaagent that we want to hook into the JVM. The Java Agent then does its dirty job before the invocation of the main method of our test program.
• Java 21 has a beautiful (internal) Class-File API for manipulating bytecode. Pretty cool thing, by the way! I’m looking forward to it coming out. We will try and use it to override a method body.

Simplest Java agent

Java Agents and Instrumentation give a lot of possibilities, such as transformation of classes when they are loaded, access to ClassLoader information and many more.

We will make a very simple Java Agent. We will create a class that implements this method:

public static void premain(String agentArguments, Instrumentation instrumentation) {}

This method, as the name suggests, is triggered before the main method of our test program. Once the implementation is done, we will specify some settings in the manifest file and create a jar package. Finally, we can use the jar package as a javaagent when we run the JVM.

Alternatively, we could have created a class transformer and added it via Instrumentation:

instrumentation.addTransformer(new BootstrapStringConcatTransformer(), true);

Then, our class transformer BootstrapStringConcatTransformer would be triggered for all classes that get loaded. However, our target class is not loaded before runtime because, before runtime, the JVM doesn’t even know what invokedynamic will need! So, we will need to load the class of interest ourselves and then redefine it.

Class-File API

There aren’t a lot of docs for the Class-File API yet. This API is not exposed to the world yet, but it’s interesting to try it out! This is the only good example of usage that I found. To be able to use it, we have to add the --add-exports option to use the closed jdk.internal.* packages.

After playing with it a bit, I got to the following code, which is not polished, but it works:

public static void premain(String agentArguments, Instrumentation instrumentation) throws ClassNotFoundException, IOException, UnmodifiableClassException, URISyntaxException {
    Class clazz = Class.forName("java.lang.invoke.StringConcatFactory"); // here we actually load the class
    ClassModel classModel = Classfile.parse(Path.of(clazz.getResource("StringConcatFactory.class").toURI()));

    var bytes =  Classfile.build(classModel.thisClass().asSymbol(), classBuilder -> {
        for (ClassElement classElement : classModel) {
            if (classElement instanceof MethodModel methodModel &&
                    methodModel.methodName().equalsString("simpleConcat")) {
                classBuilder.withMethod(methodModel.methodName(), methodModel.methodType(),
                        methodModel.flags().flagsMask(), methodBuilder -> {
                            methodBuilder.withCode(codeBuilder -> {
                                var stringClassEntry = classBuilder.constantPool().classEntry(classBuilder.constantPool().utf8Entry("java/lang/String"));
                                // using the beautiful API below, I pretty much wrote the bytecode above 1:1 to the code
                                codeBuilder
                                        .invokestatic(ClassDesc.of("java.lang.invoke.MethodHandles"),
                                                "lookup", MethodTypeDesc.ofDescriptor("()Ljava/lang/invoke/MethodHandles$Lookup;"))
                                        .astore(0)
                                        .ldc(stringClassEntry)
                                        .ldc(stringClassEntry)
                                        .iconst_1()
                                        .anewarray(classBuilder.constantPool().classEntry(classBuilder.constantPool().utf8Entry("java/lang/Class")))
                                        .dup()
                                        .iconst_0()
                                        .ldc(stringClassEntry)
                                        .aastore()
                                        .invokestatic(ClassDesc.of("java.lang.invoke.MethodType"),
                                                "methodType", MethodTypeDesc.ofDescriptor("(Ljava/lang/Class;Ljava/lang/Class;[Ljava/lang/Class;)Ljava/lang/invoke/MethodType;"))
                                        .astore(1)
                                        .aload(0)
                                        .ldc(stringClassEntry)
                                        .ldc(classBuilder.constantPool().stringEntry("replaceAll"))
                                        .aload(1)
                                        .invokevirtual(ClassDesc.ofDescriptor("Ljava/lang/invoke/MethodHandles$Lookup;"), "findVirtual",
                                                MethodTypeDesc.ofDescriptor("(Ljava/lang/Class;Ljava/lang/String;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/MethodHandle;"))
                                        .astore(2)
                                        .aload(2)
                                        .iconst_2()
                                        .iconst_1()
                                        .anewarray(classBuilder.constantPool().classEntry(classBuilder.constantPool().utf8Entry("java/lang/Object")))
                                        .dup()
                                        .iconst_0()
                                        .ldc(classBuilder.constantPool().stringEntry("^_^"))
                                        .aastore()
                                        .invokestatic(ClassDesc.of("java.lang.invoke.MethodHandles"),
                                                "insertArguments", MethodTypeDesc.ofDescriptor("(Ljava/lang/invoke/MethodHandle;I[Ljava/lang/Object;)Ljava/lang/invoke/MethodHandle;"))
                                        .areturn()
                                        .astore(0)
                                        .aconst_null()
                                        .areturn();
                            });
                        });
            }
            else classBuilder.with(classElement);
        }
    });
    // this is useful for debugging the result as the decompiled code:
    Files.write(new File("lalala.class").toPath(), bytes);
    instrumentation.redefineClasses(new ClassDefinition(clazz, bytes));
}

Packaging the agent

I compiled the Java Agent code with these options:

javac --add-exports java.base/jdk.internal=ALL-UNNAMED --add-exports java.base/jdk.internal.classfile=ALL-UNNAMED --add-exports java.base/jdk.internal.classfile.instruction=ALL-UNNAMED --add-exports java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED smthelusive/Main.java

Then, I created the manifest with the following settings:

Manifest-Version: 1.0
Premain-Class: smthelusive.Main
Can-Retransform-Classes: true
Can-Redefine-Classes: true

And packaged a jar:

jar cfm fakebootstrapagent.jar META-INF/MANIFEST.MF smthelusive/

Testing the result

For reference, this is our test program again:

public class Test {
    public static void main(String[] args) {
        String test = "something";
        System.out.println("something lalala something else " + test);
    }
}

Let’s test our program without javaagent using the java Test command. This is the result:

something lalala something else something

Now, let’s attach our javaagent (unfortunately, we need to keep all the package opening options for it to work):

java --add-exports java.base/jdk.internal=ALL-UNNAMED --add-exports java.base/jdk.internal.classfile=ALL-UNNAMED --add-exports java.base/jdk.internal.classfile.instruction=ALL-UNNAMED --add-exports java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED -javaagent:fakebootstrapagent.jar Test

Here’s the result:

^_^ lalala ^_^ else 

The concatenation is no longer concatenating 😛.

Final Thoughts

Would have been fun to replace the target method with some custom method, right? Unfortunately, that didn’t work out for me. I tried providing my custom method packaged in a jar through Instrumentation (yes, it’s also possible) so it’s available for bootstrap ClassLoader.

This code would be accessible by any code in my Test program. However, JDK internal code isn’t allowed to access the code I provide. If you know the options to “make it allowed,” please let me know.

I have also tried to add an extra method in the StringConcatHelper class, but it’s impossible to add any methods or change the signatures of existing ones. The reason is that the class is already loaded now, and the class data is stored in appropriate memory slots.

You may be wondering, why did I try this in the first place? Because, why not? Thank you for your attention, and stay tuned for the next JVM torturing episodes!

Java Invokedynamic: Bootstrapping an Alternative Method was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.

Note: if you can’t fully view this article, you can read it in my blog.

Java 21 brings in a lot of cool features, and one of them is the preview of String Templates*. While it serves more purposes than just classic String interpolation, for us Java developers, it’s yet another way to concatenate Strings in a “proper” way.

What is proper, though? I poked around the bytecode and learned some interesting and surprising things about different String concatenation and interpolation techniques in modern Java.

I’ve also compared it with the Kotlin way (under the hood) 😏.

But let’s begin with Java.

+ operator

We’ve always known that using a + operator is bad practice since Strings are immutable, and under the hood, a new String gets instantiated for every part we concatenate. However, as they say in Dutch, “meten is weten,” which means “measuring is knowing.” Let’s see what is really happening inside:

// example #1:
String example1 = "some String " + 42;

// example #2:
int someInt = 42;
String example2 = "some String " + someInt + " other String " + someInt;

// example #3:
String example3 = "";
for (int i = 0; i < 10; i++) {
    example3 += someInt;
}

In the bytecode, example #1 translates into a single String allocation. Java compiler is smart enough to see that the magic number is constant, so it is loaded as part of the String onto the operand stack:

0: ldc     #7  // String some String42

Of course, we don’t want to use the magic values, so let’s see what happens with the variables.

In example #2, the Java compiler can’t perform the same optimisation when we’re using a variable, but it does some advanced stuff with invokedynamic:

0: bipush        42
2: istore_1
3: iload_1
4: iload_1
5: invokedynamic #7,  0  // InvokeDynamic #0:makeConcatWithConstants:(II)Ljava/lang/String;

...

BootstrapMethods:
  0: #22 REF_invokeStatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #23 some String \u0001 other String \u0001

This instruction allows bootstrapping the method at runtime that needs to be called for concatenation. We’re giving it a recipe: some String \u0001 other String \u0001, which in this case, contains two placeholders. If we concatenate more variables, there will be more placeholders, but it will still be a single String in the Constant Pool.

The cool thing about invokedynamic approach is that when the newer JDK versions appear with newer concatenation techniques, the bytecode can stay the same while the bootstrap method does something more advanced (more on the current implementation a bit later).

What about example #3? In this case, the following instruction will be executed in a loop:

16: invokedynamic #9,  0  // InvokeDynamic #0:makeConcatWithConstants:(Ljava/lang/String;I)Ljava/lang/String;

This will lead to unnecessary amounts of String instances being allocated.

String::format

I had a preconception that String::format is a better alternative to the+ operator. This method can indeed offer improved readability in some cases and supports localization. Some basic benchmarking shows slightly better performance compared to concatenation. However, implementing the format method creates a new String for each parameter.

Let’s run a small experiment:

int firstValue = 12345;
int secondValue = 987654321;
int thirdValue = 117117;
String test = String.format("test %s and %s and %s", firstValue, secondValue, thirdValue);

In the bytecode, we’re placing all the values on the operand stack and simply invoking a static method:

34: invokestatic  #15  // Method java/lang/String.format:(Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/String;

Now, let’s look at the heap dump taken after this method is invoked. For that, let’s compile the program and run it with the garbage collector disabled (so it doesn’t collect the String instances before we can take a look at them):

javac --enable-preview --source=21 Main.java
java --enable-preview -XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC Main

I am using VisualVM to create a heap dump. In the String instances section, I can see the following values:

Java newest String templates

The new String template feature is good, but not because it uses memory efficiently. Actually, for basic cases, it behaves exactly the same as String concatenation under the hood. It utilizes the invokedynamic instruction passes the recipe over to the bootstrap method allowing it to do its magic.

The String templates are amazing because they can redefine the way of template processing and allow us to create other types besides String (if we want to). I enjoyed reading this article that tells more about it.

invokedynamic approach

We figured out that invokedynamic is used for most of the modern String concatenation/interpolation techniques in Java.

Is it perfect? In terms of redundant String allocation, it’s not.

We’ve seen that we’re passing the recipe (template with placeholders) as a single String. Now, if the values that have to be inserted into the placeholders are coming from the Constant Pool (the \u0002 placeholder code), then there will be no extra Strings allocated.

On the other hand, if we’re using normal variables, the placeholder code will be \u0001. In this case, at runtime, the bootstrap method creates a separate String instance for every piece between placeholders, and these Strings are combined with the parameters to construct a final String.

To see the proof of that, let’s consider this small example:

int firstValue = 12345;
int secondValue = 987654321;
int thirdValue = 117117;

// alright, we can use the fancy string templates:
String test = STR."test \{firstValue} and \{secondValue} and \{thirdValue}";

// but this line would result in exactly identical bytecode:
// String test = "test " + firstValue + " and " + secondValue + " and " + thirdValue;

In the bytecode, we see the invokedynamic with the single String which contains the recipe:

13: invokedynamic #9,  0  // InvokeDynamic #0:makeConcatWithConstants:(III)Ljava/lang/String;

...

BootstrapMethods:
  0: #27 REF_invokeStatic java/lang/invoke/StringConcatFactory.makeConcatWithConstants:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/String;[Ljava/lang/Object;)Ljava/lang/invoke/CallSite;
    Method arguments:
      #25 test \u0001 and \u0001 and \u0001

If we run the program with the garbage collector disabled and take the heap dump, we will see the following String instances (plus the resulting String, of course):

For comparison, if we used the StringBuilder instead, it would look like this:

String test = new StringBuilder()
        .append("test ")
        .append(firstValue)
        .append(" and ")
        .append(secondValue)
        .append(" and ")
        .append(thirdValue)
        .toString();

There would be only one “ and “ value allocated even if we type it in twice. There will be three String instances: two fragments and the result.

What about Kotlin?

I apologize for the lack of fun in this section, but Kotlin (1.9.0) behaves similarly to Java under the hood. The + operator as well as the plus() function and String interpolation syntax (for example, val testStr = “this is $testNum test”) all use invokedynamic.

Some versions ago, both Java and Kotlin were using StringBuilder internally to optimize String concatenation. Now they use invokedynamic, which allows to split the concatenation logic away from the bytecode (it’s sitting in the bootstrap and target methods). The implementation will probably evolve, and other JVM languages can benefit from it without making any changes (or with minor changes).

Conclusion

Regarding best practices, we probably don’t want to go against conventions. But we do want to know what’s happening inside.

What should we use? I only have the classic answer to this: it depends!

Perhaps, it’s not too bad to use regular + operator sometimes? Maybe it does look more readable in some cases (teeny tiny percent).

If we care about efficiency, we‘re better off using a StringBuilder or a StringBuffer. StringBuffer also gives all kinds of thread safety. String::format seems to work somewhat fast, but StringBuilder is a lot faster. The downside of StringBuilder is verbosity.

If we’re not too concerned about memory and speed but want to use powerful help in formatting and readability, String templates will be a great choice. Remember that they might become more efficient in newer versions and are much more than just a String interpolation mechanism.

Thank you for reading.

* The String Templates are a Preview feature in Java 21. This means that this feature is still being tested by the community; it’s not final and may change in the next versions. I’m not suggesting using preview features in production, but simply inviting you to analyse it alongside other concatenation techniques from the perspective of the internal workings.

Java 21: So How Should We Construct Strings Now? was originally published in Better Programming on Medium, where people are continuing the conversation by highlighting and responding to this story.