This goes against the very idea of method signatures in Java an overloads based on them. An attempt to add it will likely bring in way, way more backwards-compatibility pain than any benefits are worth.

Writing simple methods with few arguments helps.

The JVM has all the machinery required to do this right, though: invokedynamic.

Kotlin provides named arguments and a copy method on data classes/records that uses them. You do indeed have binary compatibility issues with them, but it's not a fundamental problem. It's just that it sits at the intersection of:

- Problems that only affect library writers, rarely a high priority for language designers (Java being a exception)

- Obscure JVM knowledge and new techniques

- Poor Android JVM holding back the ecosystem by discouraging any bytecode techniques that post-date Java circa 2010.

You can have named parameters and backward compatibility with method signatures, Groovy does that [1].

Ok, it cheats a little bit because named params are actually a syntax sugar for Maps. But other languages do the same (e.g. Python) and is very useful too. And if you can type check the map (as in Typescript) the functionality is equivalent to named params.

[1] http://docs.groovy-lang.org/latest/html/documentation/#_name...

Python has real keyword parameters, not just a syntax sugar. They're just presented as a dict when you want to see them all. And you can splat that dict when calling.

Ruby before 2.7 has a syntax sugar where keyword parameters are the same as a trailing hash. But that's changing as well.