Actually there is an existing agreement that renaming of method parameters is without consequence. Specific transforms are called out in JLS as binary compatible.

Brian Goetz

I had already mentioned my concern about the strong coupling that named parameters introduce in the first revisited post. Even though the coupling is just a strong as when a custom class is used as a parameter, developers simply do not expected this coupling on named parameters. But the fact that the specification defines that renaming parameters names are to be without consequence, makes named parameters a dead end.

And also because something else has changed since 2013… EDI’s:

And that makes the price to pay for adding named parameters not worth it.

That said, it still was fun to let the idea run through one’s head. And likewise it also is fun to see if there is a way to make this work without renaming parameters… What about using the recently added record classes? Consider this a little creative piece of code (aka it will not compile):

public Rectangle(record Parameters(int width, int height) p) {
    this(p.width(), p.height();
}

new Rectangle(new Parameters(100, 200));

Ah! Mr Goetz has kindly reacted on Twitter to the previous blog post, and lifted a piece of the curtain.

You’re mostly focusing on a non-problem; reordering can be done statically without any runtime performance cost (or semi-statically, if linkage is done with Indy.). That’s not any of the issues.

Developer blindness; focusing on part of one problem and not seeing the rest. Yes. I’m very good at developer blindness, that is why I always ask: “Did I miss anything?”. But that reordering can be done totally statically amazes me. As far as I know going from B-A (order of evaluation) to A-B (order of parameters) takes at least some CPU power. But hey, at no performance cost is good news.

But, spend some time thinking about overload selection and binary compatibility, and when that voice in your head says “we can just disallow that” when you get to the hard bits, recognize that is the siren singing to you.

Overload selection. Of course! The minute you start reordering arguments there may be multiple methods that may fit. For which one are you reordering? Consider the following two overloaded methods.

void go(int a, String b, double c);
void go(String b, int a, double c);

Now, if one would write:

go(c=1.0, b="foo", a=2);

Then this call could match any of the two methods, and the compiler would not know for which to reorder the arguments.

TL;DR named parameters seems to be possible with only a few additional in-memory copies and a bit of stack pointer manipulation. But what will it mean for debugging?

Okay, let me give this another go. In my previous post about named parameters from 2013 I think I made clear why named parameters are a good idea from the perspective of readability. And readability is the second most important aspect of source code, the first being that it should work of course. However I have not been able to convince mr Goetz to add it to Java. And I really tried a few times, ranging from online to face-to-face discussion. His argumentation every time is that it is way more complex than it seems, but unfortunately he never got around to explaining this.

Once you start with named parameters, they have a tendency to attract more and more functionality, so let’s break down what is possible in increasing complexity:

1. Documentation; the fact that for each argument you can put the name of the associated parameter in the calling statement instead of in a comment (see the 2013 post), makes the call more readable.
2. Validation; by naming the arguments in the calling statement, the compiler can check if they match the called method’s parameters. It can validate if the intention of the coder matches what is happening.
3. Ordering; if the order of the names in the call deviate from the method’s signature, the compiler could reorder the arguments to match.
4. Defaults; when named arguments can be matched to their parameter counterparts, any omissions can be filled with defaults.

void rectangle(int height = 0, int width = 0) { // these parameters have defaults
     // ...
}

void use() {
    rectangle(100, 200); // only from the call it is not obvious what this really defines
    rectangle(height=100, width=200); // better readable, and the compiler can validate
    rectangle(width=200, height=100); // the compiler could fail on this, or reorder based on the signature
    rectangle(width=200); // since all arguments are named, the compiler can infer the value for missing ones
}

Since last week everyone in the Java developer community has been stumbling over themselves because of the Log4j vulnerability. Once word got out, the log4j maintainers quickly released a fix. So if you were fairly up to date, all you had to do was upgrade a dependency and redeploy. (My project was still using log4j 1.x, so it took just a tad more effort, but that is on me.) Unless you were of course one of the people who were actually using the functionality used by the exploit, but I wager chances are small that is the case.

What I have been pondering about is if the root cause of the vulnerability is in essence really a log4j issue. Yes, log4j made it easily accessible, but the core of the issue is the fact that the JRE is completely based on dynamically loading executable code. It does so via the JNDI method which is used in the log4j vulnerability, but also simply because classes are always loaded from the file system for all Java applications. Basically moving all security constraints onto the system it runs on.