Keyword Arguments in Java

What

Java arguments are traditionally passed by position:

void foo(int x, int y, int z)

matches the call

foo(1, 2, 3)

and assigns 1 to x, 2 to y, and 3 to z in the resulting activation. Keyword arguments assign values to formal parameters by matching the parameter's name, instead.

Why

Fuck the builder pattern, okay? Patterns like

Response r = Response
    .status(200)
    .entity(foo)
    .header("X-Plane", "Amazing")
    .build();

(from JAX-RS) mean the creation and maintenance of an entire separate type just to handle arbitrary ordering and presence/absence of options. Ordering can be done using keywords; presence/absence can be done by providing one method for each legal combination of arguments (or by adding optional arguments to Java).

The keyword-argument version would be something like

Response r = new Response(
    .status = 200,
    .entity = foo,
    .headers = Arrays.asList(Header.of("X-Plane", "Amazing"))
);

and the ResponseBuilder class would not need to exist at all for this case. (There are others in JAX-RS that would still make ResponseBuilder mandatory, but the use case for it gets much smaller.)

As an added bonus, the necessary class metadata to make this work would also allow reflective frameworks such as Spring to make sensible use of the parameter names:

<bean class="com.example.Person">
    <constructor-arg name="name" value="Erica McKenzie" />
</bean>

Other Languages

Python, most recently:

def foo(x, y, z):
    pass

foo(z=3, x=1, y=2)

Smalltalk (and ObjectiveC) use an interleaving convention that reads very much like keyword arguments:

Point atX: 5 atY: 8

Challenges

Proposal

Given a method definition

void foo(int x, int y, int z)

Allow calls written as

foo(
    SOME-SYNTAX(x, EXPR),
    SOME-SYNTAX(y, EXPR),
    SOME-SYNTAX(z, EXPR)
)

SOME-SYNTAX is a production that is not already legal at that point in Java, which is a surprisingly frustrating limitation. Constructs like

foo(x = EXPR, y = EXPR, z = EXPR)

are already legal (assignment is an expression) and already match positional arguments.

Keyword arguments match the name of the formal argument in the method declaration. Passing a keyword argument that does not match a formal argument is a compilation error.

Calls can mix keyword arguments and positional arguments, in the following order:

  1. Positional arguments.
  2. Varargs positional arguments.
  3. Keyword arguments.

Passing the same argument as both a positional and a keyword argument is a compilation error.

Call sites must satisfy every argument the method/constructor has (i.e., this doesn't imply optional arguments). This makes implementation easy and unintrusive: the compiler can implement keyword arguments by transforming them into positional arguments. Reflective calls (Method.invoke and friends) can continue accepting arguments as a sequence.

The Method class would expose a new method:

public List<String> getArgumentNames()

The indexes in getArgumentNames match the indexes in getArgumentTypes and related methods.

Possibilities for syntax:

To support this, the class file format will need to record the names of parameters, not just their order. This is a breaking change, and generated names will need to be chosen for existing class files. (This may be derivable from debug information, where present.)

Edge Cases

comments powered by Disqus